Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem
When I use the domain_access module, I can restrict the access for content editing to only people which are assigned to the proper domains. But, the content translate functionality is still not restricted. So even if I can choose to let an editor to edit or not a node on his domains, I cannot choose to let the user translate or not that content.
Solution proposal
The domain_access module could expose special permissions for content translation: "Translate any content on assigned domains" and "%type_name: Translate any content on assigned domains".
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | domain_access_content_translation_2866583_11.patch | 10.55 KB | dvmanjunath |
| #10 | interdiff_2866583-7-2866583-10.txt | 3.98 KB | andreyjan |
| #10 | domain_access_content_translation_2866583_10.patch | 9.96 KB | andreyjan |
| #7 | interdiff_7_2.txt | 3.29 KB | vasi1186 |
| #7 | domain_access_content_translation_2866583_7.patch | 9.11 KB | vasi1186 |
Comments
Comment #2
vasi1186 CreditAttribution: vasi1186 at Amazee Labs commentedAttached is a first draft of the solution proposal. It still misses the tests.
Comment #3
agentrickardThis is a really interesting problem space, and I'd love for some of the other multilingual users to weigh in.
This generally makes sense to me, but I don't have a great use-case for it.
Note that Domain Access permissions are stored separately for each translation, but I think this is an extension of the ability to view/create new translations, akin to
domain_access_node_create_access().Code note:
The first function has a hard dependency on Content Translation (
content_translation_translate_access($entity);. That suggests the need for a submodule that declares a dependency on content_translation.Comment #4
vasi1186 CreditAttribution: vasi1186 at Amazee Labs commentedRegarding the use-case, here is a simple one (also exposed in the description) which can happen basically to any multilingual site: an editor does not have access to edit nodes on the domains which are not assigned to him, but because he has translation permissions for content in general, he still has the possibility to create translations, which basically means he can 'edit' (I am fully aware this is not an edit, and the original node does not get any changes) that node in a particular language, even if the node does not belong to one of his domains. At least this gives the impression that you have editing abilities on that node even if you are not supposed to. And we have a client who specifically requested that, so an editor from a domain should be just a simple visitor in regards to node operations for another domain.
The question is if that should really be implemented in the domain_access module, or in a separate one. And if that module should be part of the domain core modules, or a simple contrib module. Suggestions are welcome!
Comment #5
agentrickardI'm ok adding this to Domain Access, so long as we remove the hard dependency on Content Translation. (We'd have to wrap that in IF checks).
Really, this looks like a core bug to me. content_translation_translate_access() really should be alterable, but is not.
Comment #6
agentrickardI'm going to pop this over into the core queue for comment from the translation system maintainers. The questions here are:twofold:
* Should translators be able to create a translation for content that they cannot edit?
The original use-case here is that translators can access the translation overview page for nodes they cannot access. Should that be allowed by ore?
* Should the permission to grant translation creation be extensible / overridable via hook?
So if core thinks that condition one is ok, can we make content_translation_translate_access() fire a hook or event so that contrib modules can alter that behavior the way we do with hook_node_access / hook_node_create_access().
Comment #7
vasi1186 CreditAttribution: vasi1186 at Amazee Labs commentedAttached a new patch that fixes a bug in the previous one. In the previous one, even if you were an admin, you could not translate content unless you were assigned a domain. There should be now a permission for that.
Comment #10
andreyjan CreditAttribution: andreyjan at FFW commentedRecreated the patch to take into account changes in Drupal core 8.5.0
Comment #11
andreyjan CreditAttribution: andreyjan at FFW commentedThis issue probably should be moved rather to Domain Access then Core.
Comment #12
idebr CreditAttribution: idebr at iO commented#6.1
There is currently only a global permission to translate content that is separate to node (update) access.
An issue to introduce a
hook_entity_translation_access()for use cases such as Domains is available at #2918354: Add hook_entity_translation_access()Comment #14
bhavanasisarath CreditAttribution: bhavanasisarath commentedWhen i am upgrading the core to 8.7.1, patch #10 is failing to apply.
Is anyone having latest patch of this to support 8.7.x
Comment #15
BerdirThe patch is not for core but domain_access, so it can't apply here.
> * Should translators be able to create a translation for content that they cannot edit?
Yes, I think the current permissions are specifically tailored to use cases where translators can *only* translate (but can translate anything of a certain bundle). I agree that this is not flexible enough for many use cases.
I'd love feedback on #2972308: Allow users to translate content they can edit, which I think would make this work without any changes in domain_access.
Comment #18
dvmanjunath CreditAttribution: dvmanjunath as a volunteer and at Tech Mahindra commentedRecreated the patch https://www.drupal.org/project/drupal/issues/2866583#comment-12527212 to take into account changes in Drupal core 8.9 and making it compatible with Drupal 9.