Strict permissions during file imports

It was brought to our attention that the file importer was allowing users to perform actions beyond their project permissions. These loopholes have been closed as of this date, but you may experience errors if you are relying on previously incorrect behaviour.

If you or your team suddenly receive 403 Forbidden from import operations that were previously succeeding, it will likely be due to bugs being fixed. Likewise if you find that import processes are not applying the changes you expect, this could be due to the ignoring of privileged actions.

Summary of changes

• File imports cannot translate locales that you don't have permission to edit.
• File imports observe your level of permission to update assets belonging to others.
• Setting developer attributes on assets belonging to others requires additional permission.

Full details of changes as follows:

Restricted locale permissions

The file importer now observes permission to translate in specific locales.

Previously the system allowed anyone with permission to import files to update any locale contained in those files. This was not a problem for built-in roles, but this circumvented language specific restrictions contained in custom permission sets. This has been fixed, so check your custom roles and add translation editing permissions as needed.

Translation access being denied won't always throw an error. This is deliberate, but may leave users without full privileges wondering why their import did not do what they expected. They should check what language access they have via the dashboard before reporting this as a bug.

Specifying an explicit locale code via the Import API will produce a 403 error when uneditable, but specifying locale=auto will allow translation to fail silently. Use this option if you're importing a multi-language file and only want to extract the languages you have permission to translate.

Be warned that your source language also qualifies as a project locale and so these permissions still apply. If a file importer does not have permission to update the source locale then assets will be created with no source text.

Updating assets belong to other users

Permission to Edit asset properties must be granted to update other people's assets via file imports.

Previously the file importer would update asset properties regardless of whether the uploading user had permission to modify them. Ownership is now enforced and disallowed modifications will be silently ignored during import.

This primarily affects the built-in Manager role which has permission to add assets and use the file importer, but does not have permission to update assets created by other users. If your managers need full file importing functionality then customize their roles to add extra permissions.

See the updated documentation on the available permissions and which roles they are assigned to.

Setting developer attributes

Permission to Edit developer attributes must be granted to modify sensitive properties via file imports.

Setting certain asset properties (like ID and context) has always been a separate permission so that lower privileged users can add new assets without being confronted with technical elements. This primarily refers to the built-in Manager role which has no developer access, but is permitted to create assets.

However, anyone with access to the file importer is able to set developer attributes by uploading valid translation files. This seems like a security loophole, but enforcing permission to set developer attributes makes a nonsense of importing files. It is simply not be possible to import assets from some file formats without setting these attributes.

To avoid revoking existing access to the file importer, setting developer attributes on your own assets continues to be allowed without developer privileges, but updating these properties on assets you didn't create requires additional permission. This is a compromise between honouring project privileges and rendering file imports useless. In future it's likely that a separate permission will be added for uploading files so that this loophole may be closed by project administrators.

Import errors vs ignored actions

Denied permission won't always result in an error. The reason for this is that file imports may need to perform multiple actions. If one fails, others may still be allowed to succeed.

One example would be importing a CSV file containing many language columns. The importer will add the translations you have permission for and ignore those you don't. If it was to fail as soon as it encounters an uneditable locale, you would not be able to import anything.

Generally fatal errors are produced when ignoring an action would be damaging to the whole import, or if a specific intention is clear that would make the import pointless without it.