We identified a set of desirable aspects the ET access control system will need to satisfy:
- We want to support both a simple translation model, where translations are "normal" content and are handled the same way no matter which language they are assigned, and an editorial translation model where content admins would have full powers on content, while translators would enter translations only for a (possibily strict) subset of the entity fields (see this analysis for details).
- We need to keep the edit and translate actions separate at access control level because this is the only way to provide a straightforward permissions set allowing site builders to easily implement the translation models described above.
- We need more granularity in defining translate access, ideally all the CRUD operations should have a dedicated permission.
- We want to be able to provide per-bundle translation access control where needed.
- We want to keep the permissions page clean and avoid bloating it by adding per-bundle translate permissions for each operation for any defined entity type, as many of them might not need those. Moreover this might generate confusion as a site builder might ask herself why she has not the ability to assign edit permissions per-bundle for a certain entity type, while it's possible to limit translation access per-bundle for the same type.
To address the first two points we just need to provide different routes, associated with different access callbacks (or whatever they are called today), for editing and translating an entity. Both of them would exploit the entity form controllers to present the user an entity form, which as usual would show only the elements the user has access to.
A user with edit permissions will be able to access the edit router path in any language, thus retaining the contextual editing, which is one of the major wins of multilingual entity forms on the UX side. A user with translate permissions would instead have access to the translation overview and to the translation form, a stripped down entity form where only the multilingual elements are displayed, only the ones the user has access to obviously. In this scenario edit permissions would take precedence over translate ones, hence a user having both would access the edit form also from the translation overview, instead of the translation form.
This approach would be fairly transparent to the user (actually this is already happening in core, as translation creation is performed on a different route than editing), and would allow to choose between the two models described above by just assigning the correct permissions to the various roles.
Wrt to the permission set exposed in the permission page we just need to provide the following: access|create|edit|delete translation and delegate a more granular distinction to the single entity types. For instance Node may expose a single generic 'translate' permission for each content type, which, combined with the generic ET ones, would allow to set all combinations of access to the CRUD operations for translations with bundle granularity. OTOH User might not provide any translation-related permission and just rely on the ET ones. From the implementation perspective we just need to adjust the logic in the
EntityTranslationControllerInterface::getAccess() method. The base implementation will rely only on the ET permissions while subclasses might extend its logic as needed.
- Detailed analysis: https://docs.google.com/spreadsheet/ccc?key=0ApOIu-ZZlUJudHFwaDF4T1NhM3R....
- Analysis summary: #1829630-21: Discuss the scope of the "translate entity" permission.
- Analysis discussion on IRC.
Define the new access system model and the related permissions Implement it Add test coverage Further discussion. #53-55 seem to disagree with the current approach Postponed on above, the usual rinse and repeat:
User interface changes
ET access has been refactored to deal with the new permissions.