Updated: Comment #33

Problem/Motivation

According to #1282018: Improve UX of language-aware entity forms, there are two workflows which we should be able to support:

  • The simple workflow model is suitable for most small sites: here translations are "normal" content and are handled the same way no matter which language they are assigned. Usually in this scenario there is a single content admin role which has the same permissions on all the translation. Arguably people being assigned this role expect to deal with every translation as a standalone entity.
  • The editorial workflow model instead is more likely to be found on sites having an admin staff with different roles. Here content admins would have full powers on content, while translators would enter translations only for a (possibily strict) subset of the entity fields. Moreover translators would be unlikely to create the original content.

The current implementation of permissions does not fully support both workflows. See #21 for details.

Proposed resolution

Backport the solution developed for D8 core, which was extensively reviewed, approved and committed, and should be fully compatible with D7.

Remaining tasks

  • Investigate D8 permission model.
  • Write a patch.
  • Add tests.

User interface changes

(todo)

API changes

(todo)

D8: #1807776: Support both simple and editorial workflows for translating entities

Comments

The translate entity permissions right now regulate only the access to the translation overview. People can edit their own profile usually so they can also enter translated values. Unless I'm missing something I'd say this is by design.

Status:Active» Closed (works as designed)

Now I see the OP is talking about nodes: however the answer in #1 remains valid.

Status:Closed (works as designed)» Active

I think it's totally correct that editing the entity in any language requires an 'edit' permission. Requiring the 'translate' permission to access the translation overview is consistent with the node translation behavior, where the 'translate' permission regulates the access to the translation overview and to the translation form elements. Translation creation is regulated by the separate 'create' permission. To match exactly this model we would need a new permission 'create translation'. Alternatively we could exploit the 'translate' permission to regulate the translation creation, but I'd see this as a somehow inconsistent behavior because a translator could create a translation but not edit it. Another possibility could be to limit access also when editing a translation to roles having a 'translate' permission, but this would make the 'translator' a more powerful role than the 'editor', since the former could access the entity also in non-default languages, while the latter could only edit the original values.

Overall I still think the current approach is the most correct, but I'm totally open to revisiting this.

So far I've associated the "translate XY permission" as the permission which controls access to the task of "translating something", which by my understanding includes the task of "adding" or "editing" the translation of a normal node... that's mostly because of the permission title and description, which talks explicitly about translating "field content", and NOT about accessing the translation overview page.

$permission["translate $entity_type entities"] = array(
'title' => t('Translate entities of type @type', array('@type' => $label)),
'description' => t('Translate field content for entities of type @type.', array('@type' => $label)),
);

So we could leave permission access as it is now and just clean up the permission description.

However, in that case, I think we're still missing the counter-part to "edit original values", i.e. something like "edit translation values". That would be useful for anyone who wants to completely hide translation forms from "normal" content editors.

I asked Gabor to chime-in since this choice will probably affect also D8 core.

Title:User can access translation forms without the "translate entity" permissionDiscuss the scope of the "translate entity" permission
Category:bug» task

I think this is a pretty complex question :) Ideally translators should be able to translate entities without permissions to edit the originals, that is a pretty basic requirement on some multilingual sites. So

- edit would give you access to the original content; I think also to the translations to be edited
- translate would not give you access to edit originals, but you would be able to edit (in which case you probably should not be able to edit shared values if you don't have edit access to those)

Of course in this model editing and translations have a relationship where editing is the major action and it encompasses translations while translations is the more strict one (and combined with edit could give you access to edit original values).

I don't see how the "edit original values" permission on its own would work, in my view if that is granted, you effectively grant edit permissions, which is well, already present. Unless we restrict edit to the originals only, but in that case the core permissions should be understood as such.

Well, what can I say? #7 makes perfectly sense and is far more simple to configure than our current appproach with workflow permissions. We would still lack the ability to restrict editor access to just original values, but we never had something like that so far, so I think it's not a big deal.

As dicussed with @Berdir in another issue, the aim of ET should be providing a set of permissions allowing to setup sensible translation access control for the most common cases. Any more advanced workflow will require something like TMGMT anyway.

I'd say we want to move to the approach described in #7: it provides exactly the right balance between simplicity in configuration and granularity in access control for the scope of ET.

Benedikt, what do you think?

@Gabor:

Do we need a separate permission to access only the translation overview page?

@plach: I think if you have permissions to edit or permission to translation the entity type, you should have access to the translation screen. If you cannot translate and not edit, I assume you are thinking you might want to have an overview of translation status. We should be able to fall back on a generic admin permission for that case(?). Eg. access admin pages? (I know the translation pages are usually not appearing in the overall admin realm, but they are kind of content admin experiences).

I think if you have permissions to edit or permission to translation the entity type, you should have access to the translation screen.

Not sure editors should have access to the translation overview, nor to the translation settings onto the entity form.

I assume you are thinking you might want to have an overview of translation status. We should be able to fall back on a generic admin permission for that case(?)

Yes, this may work, but I think that having the edit permission on entity should not be enough to access the translation overview.

@plach: well, in my model in #7, edit allows you to edit THE ENTITY, and since translations are parts of the entity, then edit permissions should allow you to edit regardless of translation. For example, it lets you affect the shared fields on all translations, so technically even if you can only edit the source, you can change translations. In my model in #7, if you have edit, you have translate, and if you don't have edit, then you can be granted translate only. Of course this all stems from the understanding that translations are WITHIN entities, and editing an entity traditionally allows you to do anything with all the data on the entity.

I agree with #12, but I think that "being able the edit any value in any language" !== "translate an entity". With node translation I can edit any antity but still have no access to the translation overview and the translation widgets.

If you wish to let your editor acces the translation overview just grant them the related permission: this won't let them edit more things that they are already allowed to, but with my proposal you can emulate more "node translation" behaviors than with yours.

I think the question is more what makes sense :) I'm not sure node translation permissions were well planned out and thought through :D If you have edit rights to any language version of the node, you could compose a mental map of status for each, so why do we not let you get to that overview right away without more hassle?

Yes, #7 makes sense to me as well...

Gabor: In my model in #7, if you have edit, you have translate, and if you don't have edit, then you can be granted translate only.

Can we change that and just completely separate "translate" from "edit"? This would mean, that ...

  • users with just edit permissions can edit normal nodes including shared values, but do not have access to anything related to translations
  • users with edit and translate permissions can edit normal nodes as well as translations, and access the translation overview
  • users with just translate permissions can access the translation overview, add translations and edit them, but do not have access to shared values nor the original entity form.

This would make sense for me because, in my experience (i.e. for my users) the whole process of "translation" is something that's not strictly tied to "normal" content editing, i.e. I would argue that users would not necessarily expect to get access to translation creation/editing if the only have the "edit permissions".


For reference, we currently have the following permissions:

Administer entity translation
Select which entities can be translated.
Toggle field translatability
Toggle translatability of fields performing a bulk update.
Translate any entity
Translate field content for any fieldable entity.
Translate entities of type [Type]
Translate field content for entities of type [Type].
Edit shared values
Edit values shared between translations on the entity form.
Edit [Type] shared values
Edit values shared between translations on [Type] forms.
Edit original values
Access any entity form in the original language.
Edit original values on entities of type [Type]
Access the entity form in the original language for entities of type [Type].

@bforchhammer: what do you do if you have edit permission but no translations permissions and want to edit a shared (non-translatable) field? You'd change translations then and there.

@bforchhammer: what do you do if you have edit permission but no translations permissions and want to edit a shared (non-translatable) field? You'd change translations then and there.

Right, it still would not be entirely separate. But that's also why we have the "(all languages)" suffix for shared fields, to make the user aware of what he's doing...

Another possible issue: if we change things so that translators no longer require edit permissions, we loose the ability to restrict translation access on a per-bundle basis (e.g. "translate only article content"). That's currently possibly by combining respective edit and translate permissions...

Right, it still would not be entirely separate. But that's also why we have the "(all languages)" suffix for shared fields, to make the user aware of what he's doing...

Well, permissions are not to inform people as to what they do, they are to limit access. I think if we attempt to separate edit from translate permissions we should at least document that both would allow editing shared fields. If the shared fields permission is its own thing, then if you enable the translation module, you loose access to shared fields even if you had edit access, which is pretty bad.

I think if we attempt to separate edit from translate permissions we should at least document that both would allow editing shared fields.

Hm, my thoughts in #15 were actually to tie shared fields access to the "edit permission" for original values, i.e. users who have only the translate permission would not have access to shared fields at all.

Edit: I'll try to read through some of the older issues tomorrow to get a better feeling for the different use cases/workflows which we should support.

I looked through different issues in an effort to summarize "access control requirements" for entity translation. Some of the points below may go a bit beyond the question of what do with the "translate entity" permission, but maybe this can also help with #1807776: Support both simple and editorial workflows for translating entities. I hope I didn't miss anything major. :)

Requirements

According to #1282018: Improve UX of language-aware entity forms there are two workflows which we should be able to support:

  • The simple workflow model is suitable for most small sites: here translations are "normal" content and are handled the same way no matter which language they are assigned. Usually in this scenario there is a single content admin role which has the same permissions on all the translation. Arguably people being assigned this role expect to deal with every translation as a standalone entity.
  • The editorial workflow model instead is more likely to be found on sites having an admin staff with different roles. Here content admins would have full powers on content, while translators would enter translations only for a (possibily strict) subset of the entity fields. Moreover translators would be unlikely to create the original content.

In addition to supporting these two models, the following issues/questions have been raised:

  1. Consistency with "content translation" module: in the old model, the "edit" permission effectively granted access to all translation editing and the "translate" permission only granted access to the translation overview. Question is, whether we actually need/want to be consistent. Gabor says, it's more important to do "what makes sense" (#14).
  2. Alignment to traditional understanding of the "edit" permission: traditionally, it allows you to do anything with all the data on the entity. If we consider "translations" to be "part of" entities, then the edit permissions should include access to translations. (#12)
    • If that's the case, should edit permissions also include the "creation" and "deletion" of translation values, or should these instead align with the traditional "create entity" and "delete entity" permissions?
  3. It is a big problem if users loose access to something after enabling the ET module, so this should just not happen! (#19)
  4. There is the problem of shared fields affecting the original entity as well as all translations. It should be possible to edit translation values without having access to shared fields (that's already possible). An open question (in respect to permissions) is whether access to shared fields should imply edit access to translations.
  5. Per-Bundle access control: for example, do we need to be able to restrict translators to certain content-types? This is currently possible with ET, and I think webchick also expected this from the core patch.
  6. Per-Language access control: for example, do we need to be able to restrict translators to values in certain language only? Outside the scope of this issue

Access objects

The following is a list of tasks/actions which I think we need access checks for. (Some of these may seem redundant, but are included because they're handled differently in the current permission model.)

  • (T1: create entity)
  • T2: edit entity which has no translations
  • T3: create translation (any language)
    • T3.1 edit shared values during translation create
  • T4: edit entity which has translation
    • T4.1: original values (original language)
    • T4.2: translation values (any language)
    • T4.3: shared values (on original language form)
    • T4.4: shared values (on translation form)
  • T5: delete translation
  • T6: access translation overview

Comparison of permission models

I put the tasks above in a matrix against different permissions models, to make it easier to compare current and suggested models: google spreadsheet (edit access for anyone with link, go wild!)

Model 1 (#7) makes it easy to map permissions to the workflow models above (edit permission => content editor, translate permission => translator). This means that no or very little time needs to spend on setting up permissions. Anything that goes beyond the two default workflow models will be difficult.

Model 2 (#15) allows a bit more flexibility, but requires that the translate permission is granted before users can do anything related to translations. This supports the additional use-case of "editors without translation access".

Both models have the same problem with respect to shared fields (editing them also changes translations); the first model may be easier to comprehend for users because they have edit access to all language versions.

From a software-design perspective, the 2nd model seems a bit cleaner because permissions do not overlap. Also, combining finer-grained permissions within a role is simple, but splitting up a larger-grained one requires extra development.

Generally, I got the impression that "translating" means different things to different people:

  • the whole translation workflow, which includes being able to see the overview, creating, editing and also deleting translations
  • just the process of "creating a translation" (and possibly editing it); i.e. taking sentences in one language and transforming them into another.
  • just parts of translation management: seeing the overview + deleting (current model)

This lead me to the question of whether it would be good to completely remove the "translate" permission and replace it with separate permissions which are named more precisely: create translation, edit translation, and delete translation (Model 3). In comparison to model 1, this would be essentially the same as model 2 with some additional flexibility and a little more work for users during the initial setup.

Great deep analysis! Wow! Looks like model 3 is indeed the most flexible, so we'd basically have all the node permissions in "* translation" versions. That sounds like a huge proliferation of permissions for translation but would let users understand the matching pieces better.

StatusFileSize
new15.85 KB

Gabor:

Benedikt and I had a very long discussion about this and the D8 equivalent. I think I'm reaching a possible solution, at least for D8, but I need to reorder my thoughts. Will post them tomorrow on the D8 issue.

Here is the IRC log if you are interested.

StatusFileSize
new15.85 KB

It seems it doesn't work. Posting it again.

StatusFileSize
new10.85 KB

Being able to assign translators that are able to translate content that has been created in a particular language without having access to edit the original content is a complete killer feature for me and for most of our clients. I have posted a patch for a previous version of entity translation that allows for translating content without having access to the original before and this is currently a blocker for NodeStream, a distribution that incorporates entity translation as one of the key components.

This is by no means a complete patch of course: there is a lot to be done, for one there needs to be tests, especially since this concerns a significant part of the access system that needs to be respected, so I'm just posting this patch as a reference point for now. I will continue working on it, but I want to provide the progress I have made if someone wants to continue before I have the time to do so.

I would like ET permissions to follow the D8 proposal...

I've created a topic branch for this issue, as this will require quite a few changes. It's still completely non-functional at the moment, I have only added permissions, updated the handlers and played around with the permissions page so far (commit-diff). Not sure how much time I'll have before the end of the year, so feel free to jump in if you can.

Ok, let's wait to find an agreement there, though.

Jumping here from http://drupal.org/node/1875280

@Platch: in any case, may a more granularity in entity translation permissions give rise to a new feature request? I think this can be useful to many: think at "community websites" where common users can translate their own content, but obviously they don't need (and must not have!) the possibility to change the translation author (that is always themselves because they don't share their translations) or to mark their own translations as outdated.

To reach the above result actually a hook_form_alter is necessary.

Is it possible to have an additional "access translation options/fieldset" permission instead?

Thank you very much for considering this.

The core issue has been committed on the 8.x branch and the good news is that the approach taken should be fully "backportable".

Version:7.x-1.x-dev» 7.x-1.0-beta2

Fully support the need for #21 'editorial workflow model' + Requirement 6 - Per Language Access Control.
Use Case: a Museum has a number of curators who create/edit original content in English; this content is translated into 6 different languages by 6 different people who should not be able to edit each others translations or the original source.

I'd like to hide the Translation fieldset to be hidden on the node edit page (it is confusing for my use case).
Given that there is not yet a permission to handle this, how can it be done?

in hook_form_alter() a dpm($from) does not show a translation array (vertical must be handled differently) and doing things like that seuggested on http://drupal.org/node/1875280 don't work
$form['translation']['#access'] = FALSE;

Thanks in advance

Version:7.x-1.0-beta2» 7.x-1.x-dev
Issue tags:+Needs issue summary update

Tagging. D8 API freeze and perhaps we all have a bit more time to discuss the issue but first if someone could update the issue summary so we have a clear view of what needs to be hashed out.

Title:Discuss the scope of the "translate entity" permissionImprove workflow permissions (match D8 solution)

I just updated the issue summary with my thoughts of what should be done next.

The issue summary and the related proposal looks good to me. Patches welcome :)

Issue summary:View changes

Added issue summary