There is currently only one assignable user permission for i8ns Translation module: "Translate nodes". Giving a user this permission makes the "Translation" tab appear for all translatable nodes. I would like to request the addition of a "Translate own nodes" permission which causes the "Translation" tab to show up only for those nodes owned by the user.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

5ven’s picture

FileSize
2.28 KB

In Drupal 6 it was easy, although I needed to change the core files. Here's the patch for it. There will "translate own content" - access right item at the admin side.

nedjo’s picture

Project: Internationalization » Drupal core
Version: 5.x-2.3 » 7.x-dev
Component: Miscellaneous » translation.module

Moving to correct project, Drupal core.

j.somers’s picture

Status: Active » Needs review
FileSize
2.79 KB

Attached is a D7 implementation of the patch from comment #1.

cburschka’s picture

Status: Needs review » Reviewed & tested by the community

Looks good, but we may need a unit test case for this permission...

Dries’s picture

Status: Reviewed & tested by the community » Needs work

Agreed with #4. Let's make sure we add some tests for this, and related functionality. Thanks!

j.somers’s picture

Status: Needs work » Needs review
FileSize
4.12 KB

Attached is a simple addition to the existing translation test. A new user is created and an attempt is made to translate a node which has not been created by that user.

Please let me know if a bigger test needs to be created or something else has to be added.

catch’s picture

Status: Needs review » Needs work

We should probably check for a 200 when they translate a node they do have permission to translate as well. Otherwise looks good.

sun.core’s picture

Version: 7.x-dev » 8.x-dev
spacereactor’s picture

If this is push to drupal 8 than is another 2 more years of waiting time. If each user wish to translate their own content will work better for a community, by restricting a site to a small group of trustworthy users to translate the whole community site is not very effective. Sorry i not a programmer but do hope that is can resolve. Thk!

FiNeX’s picture

Wouldn't be possible to apply the patch on http://drupal.org/node/253157#comment-1153121 in D6 ??????

FiNeX’s picture

FileSize
2.36 KB

this patch is wrong, dont' use it

FiNeX’s picture

FileSize
2.42 KB

this patch is wrong, dont' use it

spacereactor’s picture

I use #11 and global content translate premission is broken so all admin can't translate like what FiNeX say but using #12 got another problem, those with translate permission all turn user1 account when they try to translate node. Can someone confirm this or maybe i mess up the patch. Thank.

FiNeX’s picture

@Spacereactor: what do you exactly mean with "all turn user1 account" ?

spacereactor’s picture

I using manually patching your #11 and after that reset my user permission for content translate and own translate. when i user a normal account to login example user20, when i click translate node this user20 turn to user1.

FiNeX’s picture

Probably you have some other issues on your setup: I've just tested the patch on a clean drupal installation and when I click on "translate node" the user doesn't change.
Moreover if you look at the source code of the patch you can see that it is just a check on the access control.

spacereactor’s picture

I remove all other modules expect drupal 6.16, i18n, token, and views.

I have 4 roles, anonymous user, authenticated user, admin, contributor
Admin is set all user permissions to yes and Contributor is able to create node, edit own node, delete own node and translate own content.

I have 3 users,
user1=myself(super user)
user2=admin role
user3=contributor

After i create a new node with super user account(user1), logout from user1 and login as user3, see the node and can't translate, logout from user3 and login as user2 with admin role, user2 see the node and translate button, once click on the translate button, user2 automatic switch to user1. (something is not right here)

I use user3 with contributor role, create a new node, user1 and user2 can translate that own, but user3 can't translate own node. And when user2 try to translate the user3 node, it change to user1 when click on translate button.

Maybe i didn't apply the patch correct but this is what is getting from manual add patch #11

spacereactor’s picture

FileSize
5.1 KB

i zip the translation.module and you can check if i mess up the manually patch.

greenc’s picture

+1

FiNeX’s picture

I've done some extra testing and I've had your same problem... I'm trying to find the problem. Thanks

FiNeX’s picture

Please, don't use the patch I've uploaded for D6: it doesn't work and has a critical security bug.

You can try using the first patch uploaded here: http://drupal.org/node/253157#comment-1153121

P.s: why the version of this bug has been set to D8 ???

dokumori’s picture

@FiNeX - your comments with the patches have been removed from this issue.

dokumori
Security Team coordinator

FiNeX’s picture

Thanks @dokumori :-)

minff’s picture

I have found that all you have to do to remove translation tabs (and translation rights) from nodes that are not assigned to people (i.e. that are not theirs to edit) is to change the function _translation_tab_access in translation.module, adding there node_access control for updating. It should look like this:

function _translation_tab_access($node) {
  return !empty($node->language) && translation_supported_type($node->type) && node_access('view', $node) && node_access('update', $node) && user_access('translate content');
}

This works well with Node Access User Reference.
PS. This goes for Drupal 6.19 + Internationalization 6.x-1.7

nyleve101’s picture

Just a quick note for anyone else looking for this that it's been turned into a mini module http://drupal.org/project/translation_own_nodes.

plach’s picture

Maune’s picture

Status: Needs work » Needs review

#1: translate-own-nodes.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, translate_own_nodes.patch, failed testing.

Gábor Hojtsy’s picture

Issue tags: +Novice, +D8MI, +sprint

While introducing this feature, it would be important to qualify the other permission. Like "Article: edit own content" / "Article: edit all content" etc. are structured. So at the same time sounds like we should rename "translate content" to "translate all content" to conform to this structure, qualifying that "translate own content" is in itself enough to grant, and there is no need to grant "translate content" (especially since it is wider).

Putting on D8MI sprint as a Novice issue to help people pick it up.

plach’s picture

We should also keep in mind that we might need to extend these permissions to any entity type.

Gábor Hojtsy’s picture

@plach: Well I guess Drupal core should rather have edit/create content permissions per node types which combined with translate permissions would let you create translations, no? A little gotcha there is of course that field translations are really node edits while node translations are node creations (even though we still plan to remove this later method).

fastangel’s picture

Status: Needs work » Needs review
FileSize
8.38 KB

Hi guys,

I attach a new patch with change of comment #1 and renamed the permission (I changed all call to this permissions)

Regards.

Gábor Hojtsy’s picture

Status: Needs review » Needs work

@fastangel: Looks pretty good, thanks for picking this up! Sounds like what we need is:

- upgrade path for permission rename
- new tests for the new permission to verify that granting that only grants translation perms to your own content

Gábor Hojtsy’s picture

Tagging up.

jibran’s picture

- upgrade path for permission rename
- new tests for the new permission to verify that granting that only grants translation perms to your own content

Don't know how to write a test.

fastangel’s picture

I have some questions:

  • The test will be implemented in: "core/modules/translation/lib/Drupal/translation/Tests/TranslationTest.php" ??
  • It would be necessary to create another class for the test??. Because now is to create content "TranslationTest" (all content translate) and meaningless name. What do think?. If you think well I can get down to work.
Gábor Hojtsy’s picture

Issue tags: -Novice

We in fact need two kinds of tests:

- upgrade tests (these are under system module, have language tests there for upgrade path related stuff)
- functionality test (for setting users with this permission and checking access to various nodes)

The second type of test can indeed go to the existing translation test case, if that is already for testing the "translate content" permission :) You'll find existing language upgrade tests with the system module, the new upgrade tests should go there. I think this got complex enough to loose the Novice tag (unfortunately).

penyaskito’s picture

Rerolled patch from #35. Translation tests passes, but cannot launch all tests and QA is down temporally, so I don't set to "Needs review".

penyaskito’s picture

Status: Needs work » Needs review

QA is enabled again, let's check the reroll was fine.

maxtorete’s picture

Assigned: Unassigned » maxtorete
FileSize
2.62 KB
10.85 KB

Hi,

Here at Penyaskito home are 3:30am and we are closing tonight sprint, I upload this WIP patch for functionality test. Tomorrow morning I'll finish it.

Greets!

sxnc’s picture

Just tested this locally and it worked fine for me with a user having only the permission to edit his own nodes.

maxtorete’s picture

Assigned: maxtorete » Unassigned
FileSize
11.15 KB

I have added a new assertion to check that a user with "Translate own content" role can't get the create translation form via URL, and it fails because this condition isn't check, so the user can create a translation of other user's content.

For example, on a multilingual site (en, es) a user X creates a node with nid 23 on english language. Other user Y with "Translate own content" role opens node 23 and can't see translate link (so it's working fine), but if she types on her browser the url http://mysite/node/add/page?translation=23&target=es she (Y user) must get a 403 page, but instead she gets the translate form and can send a translation for other users node.

Because translations won't become new nodes anytime soon, should we just ignore this, or an action should be taken?

Gábor Hojtsy’s picture

Status: Needs review » Needs work

@Maxtorete: hm, if we want to have this permission enforced, then we should not leave holes like that :) When this is ported to entity translations (instead of creating new nodes), we will port this there, but we need to fix it here now. Let's fix that too.

maxtorete’s picture

Assigned: Unassigned » maxtorete

Ok, I'm working on it now ;-)

I can't find language upgrade test on system module, where are them?

Gábor Hojtsy’s picture

The upgrade test database dumps are in core/modules/system/tests/upgrade/, the actual tests are in core/modules/system/lib/Drupal/system/Tests/Upgrade/LanguageUpgradePathTest.php

maxtorete’s picture

Status: Needs work » Needs review
FileSize
11.78 KB

I have fixed the issue pointed on comment 42.

Now I have another doubt, If a user has the "Translate all content" but not the "Create new content", he can't translate content. I think this could be wrong, because, for example, you want to give access to a professional translator to translate current content but not to create new.

Gábor Hojtsy’s picture

I think THAT is fine though, or at least definitely out of scope for this patch. Also, since we are targeting to remove node copy as translations, people will not need the create content permission to add translations eventually hopefully.

maxtorete’s picture

Ok thanks, waiting then to patch test & review.

Gábor Hojtsy’s picture

Status: Needs review » Needs work
+++ b/core/modules/translation/lib/Drupal/translation/Tests/TranslationTest.phpundefined
@@ -250,6 +251,35 @@ class TranslationTest extends WebTestBase {
+    ¶
+    // Try to change to translate with "brute force".

Extra whitespace on the empty line. Should have no spaces.

+++ b/core/modules/translation/translation.installundefined
@@ -0,0 +1,17 @@
+/**
+ * Rename the translate all content permission.
+ */

You are in fact renaming the "translate content" permission :)

+++ b/core/modules/translation/translation.moduleundefined
@@ -37,7 +38,7 @@ function translation_help($path, $arg) {
+      $output .= '<dd>' . t('Users with the <em>translate all content</em> permission can translate all content, if the content type has been configured to allow translations. To translate all content, select the <em>Translations</em> tab when viewing the content, select the language for which you wish to provide content, and then enter the content.') . '</dd>';

"To translate all content" in the help text sounds like a search and replace issue, should just be "translate content" AFAIS.

+++ b/core/modules/translation/translation.moduleundefined
@@ -67,7 +68,7 @@ function translation_menu() {
- * Access callback: Checks that the user has permission to 'translate content'.
+ * Access callback: Checks that the user has permission to 'translate all content'.
  *
  * Only displays the translation tab for nodes that are not language-neutral
  * of types that have translation enabled.
@@ -81,8 +82,10 @@ function translation_menu() {

@@ -81,8 +82,10 @@ function translation_menu() {
  * @see translation_menu()
  */
 function _translation_tab_access($node) {

Should update the explanation, the code is not just checking the translate all content permission anymore, its more complex.

+++ b/core/modules/translation/translation.moduleundefined
@@ -155,8 +161,13 @@ function translation_node_type_language_translation_enabled_validate($element, &
+    global $user;
     if (!empty($node->translation_source)) {
-      // We are creating a translation. Add values and lock language field.
+      // We are creating a translation. Check if user has permissions for it
+      // and add values and lock language field.
+      if (!user_access('translate all content') && !($node->translation_source->uid == $user->uid && user_access('translate own content'))){
+        throw new AccessDeniedHttpException();
+      }

Can we put this kind of code in a hook_node_access() somehow? It looks like being at an dd place in the middle of a translation form alter to throw the user out like we do. From a node access hook, we can just check the create op and if a translation is being created somehow. That sounds like could hold its own problems, but at least it would be in the access checking flow :)

maxtorete’s picture

I tried it but I can't get a way to load node details on hook_node_access, I will look for it again :-)

maxtorete’s picture

Ok, now I've got the problem, "translation_node_access" is being called more than once on the same request, only has to get the correct one.

maxtorete’s picture

I don't get any way to use hook_node_access to control permissions, because on create we only get the node type on $node.

maxtorete’s picture

I have found the bug, it is on translation_node_prepare, no need to implements hook_node_access :-). I will fix later!

maxtorete’s picture

Anyway, I'm going to implement hook_node_access, because if it isn't implemented the user gets a blank create node form and could send it creating a new node (thought not a translation).

maxtorete’s picture

Status: Needs work » Needs review
FileSize
12.65 KB

New patch attached. I have moved permission check from hook_node_prepare to hook_node_access and create a new function to check if a user can translate a node.

penyaskito’s picture

Status: Needs review » Needs work
+++ b/core/modules/translation/lib/Drupal/translation/Tests/TranslationTest.phpundefined
@@ -250,6 +251,35 @@ class TranslationTest extends WebTestBase {
+    $node = $this->createPage($this->randomName(), $this->randomName(), 'en');
+    $this->assertLinkByHref('node/' . $node->nid . '/translate', 0, t('User with "translate own content" role can see translate link'));
+    $this->drupalGet('node/' . $node->nid . '/translate');

We don't need to wrap test messages in t(). See http://drupal.org/simpletest-tutorial-drupal7#t. But the way the rest of the tests in the same file use t() on messages. Maybe we can leave this, but create a follow-up issue for cleaning this.

+++ b/core/modules/translation/lib/Drupal/translation/Tests/TranslationTest.phpundefined
@@ -250,6 +251,35 @@ class TranslationTest extends WebTestBase {
+    $this->drupalGet('node/' . $node->nid . '/translate');
+    $this->assertResponse('403', t('User with "translate own content" role can\'t get translate page'));
+
+    // Try to change to translate with "brute force".
+    $this->drupalGet('node/add/page', array('query' => array('translation' => $node->nid, 'target' => 'es')));
+    $this->assertResponse('403', t('User with "translate own content" role can\'t get create translate page'));

Use 403 instead of '403'. There are several cases.

+++ b/core/modules/translation/translation.moduleundefined
@@ -104,13 +108,46 @@ function translation_admin_paths() {
+    $source_node = node_load($_GET['translation']);
+    if (empty($source_node) || !translation_user_can_translate_node($source_node, $account)){
+      return NODE_ACCESS_DENY;
+    }
+  }
+
+  return NODE_ACCESS_IGNORE;
+}
+
+/**
+ * Check if the user has permissions to translate a node.
+ *
+ * @param $node
+ *   Node being checked.
+ * @param $account
+ *   User object to check translation permissions.
+ *
+ * @return
+ *   TRUE if the user can translate a node, FALSE otherwise.
+ */
+function translation_user_can_translate_node($node, $account) {
+  return node_access('view', $node, $account) && (user_access('translate all content', $account) || ($node->uid == $account->uid && user_access('translate own content', $account)));
+}

I'm not sure if we should use an auxiliar function. In any case, it should be prefixed with an _, I don't think we want to expose this as API.

AFAIK, Drupal core standards say:

$can_access_node = node_access('view', $node, $account);
$can_translate_all = user_access...;
$can_translate_own = ...

if (empty($source_node) || ($can_access_node && ($can_translate_all || $can_translate_own))) {
// Whatever.
}
maxtorete’s picture

Assigned: maxtorete » Unassigned
Status: Needs work » Needs review
FileSize
14.29 KB

New patch uploaded with upgrade test!

We don't need to wrap test messages in t(). See http://drupal.org/simpletest-tutorial-drupal7#t. But the way the rest of the tests in the same file use t() on messages. Maybe we can leave this, but create a follow-up issue for cleaning this.

Ok, I will create the new issue.

Use 403 instead of '403'. There are several cases.

Done.

I'm not sure if we should use an auxiliar function. In any case, it should be prefixed with an _, I don't think we want to expose this as API.

AFAIK, Drupal core standards say:

That permission is checked more than once so I think it could help on future changes on translation system if we left it on an auxiliar function.

Also I don't know if we should hide the function, it could be used by other functions or modules to check if a user can translate a node. Maybe we could refactor some functions on location.module to check user translation permissions, for example when listing links to translate actions, so once the translation system is migrated from the current node copy system we only has to modify that function.

pp’s picture

Status: Needs review » Needs work
+++ b/core/modules/translation/translation.module
@@ -37,7 +37,7 @@ function translation_help($path, $arg) {
+      $output .= '<dd>' . t('Users with the <em>translate all content</em> permission can translate all content, if the content type has been configured to allow translations. To translate content, select the <em>Translations</em> tab when viewing the content, select the language for which you wish to provide content, and then enter the content.') . '</dd>';

Why not contains the help text information about "translate own content" permission?

+++ b/core/modules/translation/translation.module
@@ -265,24 +303,17 @@ function translation_node_view(Node $node, $view_mode) {
 function translation_node_prepare(Node $node) {
+  global $user;

Is "global $user" necessary?

Tests run well.

maxtorete’s picture

Why not contains the help text information about "translate own content" permission?

This text come from a previous patch, I think it's search & replace issue, fixed.

Is "global $user" necessary?

No it isn't, after implementing hook_node_access the user object isn't used anymore on that function. I forgot to delete that line, thanks for pointing it.

New patch with these corrections added.

maxtorete’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, translate-own-nodes-253157-59.patch, failed testing.

maxtorete’s picture

Status: Needs work » Needs review
FileSize
13.73 KB

I forgot to add module.install in last patch... :-(

maxtorete’s picture

Ignore last patch, this is the correct one.

fastangel’s picture

One comment about this function: translation_user_can_translate_node($node, $account). I think that the best form is translation_user_can_translate_node($node, $account = NULL) if $account is null then use a user logged on the web. With this I think you can save declare global $user. (I think this function will be usually called with the default user). What do you think?

Regards.

maxtorete’s picture

I think you are right, patch attached with that change.

mlecha’s picture

Just tried the #63 patch in D7, which worked. The patch has the functionality I need. Is this the sort of thing that gets backported to D7? If not, could it be ported to a module that overrides the core functions?

Thanks for your patience...

Status: Needs review » Needs work

The last submitted patch, translate-own-nodes-253157-65.patch, failed testing.

maxtorete’s picture

Status: Needs work » Needs review
FileSize
13.71 KB

Fixed warning from comment 65 patch.

pp’s picture

Status: Needs review » Reviewed & tested by the community

I think this patch(68) is good for commit.

Bojhan’s picture

Status: Reviewed & tested by the community » Needs work

Ehh, we dont allow the word "nodes". This should be "Translate own content" see http://drupal.org/node/604342.

Or is the issue title wrong? then never mind my comment.

Gábor Hojtsy’s picture

Title: Add a new user permission "Translate own nodes" » Add "Translate own content" permission, rename "Translate content" to "Translate all content"
Bojhan’s picture

Status: Needs work » Reviewed & tested by the community

Heh, sorry - back to RTBC.

penyaskito’s picture

Dries’s picture

Status: Reviewed & tested by the community » Fixed

This looks good to me. Committed to 8.x. Thanks all.

I'd like to see us update CHANGELOG.txt with this and other recent D8MI additions.

Gábor Hojtsy’s picture

Thanks Dries. We will get to submitting CHANGELOG.txt patches and change notices soon. So far the important focus was to get stuff committed before they become stale and people wander off :)

Gábor Hojtsy’s picture

Added http://drupal.org/node/1776752 as a change notice for this. CHANGELOG.txt patch forthcoming from rvilar.

Gábor Hojtsy’s picture

Issue tags: +language-content

Add missing language-content tag.

Gábor Hojtsy’s picture

Issue tags: -sprint

Changelog action happening in #1777870: Catch up changelog.txt with recent languages changes, removing off sprint. Thanks all!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

rameshbabu.g’s picture

Hi Somers,

Thank you for your patch . It works for me.
By using this I got one more permission on translation i.e 'Translate own content' .It is fine
But here one more complication is there .I need to restrict 'Translate own content ' permission to particular content type .
Can you/anyone please suggest me to reach this ...(I m using drupal 7)

Thanks in advance.

mlecha’s picture

FileSize
45.82 KB

I'm testing this both in Drupal 8.x-dev and the patch at #1 above in D7.

Not sure if this is a bug, or if my use case is an anomaly?

We're a non-profit selling job postings on a job board. After the user has paid for and posted their job, access to "Create new content" is revoked. But they still need access to translate their own posting for free.

These users have permission to "Translate own content" but not to "Create new content".

In that scenario the translation tab shows up, but not the link (or permission) to "Add a translation".

translations

Any advice would be much appreciated. Easy fix?

Or a bounty could be offered for a custom fix.

mlecha’s picture

Found that I could add a condition in translation.pages.inc to make the add translation link appear:

if ((node_access('create', $node)) || (($node->uid == $user->uid) && user_access('translate own content'))) {

But that link only leads to an "Access denied" when the node is attempting to be created. Looking for where in core that permission is checked?

Gábor Hojtsy’s picture

Translation is a node crreation, so the user needs that permission too. If you want to prevent them from submitting further untranslated content, you would need to have write some custom code to catch that situation on node creation, if it is not created as a translation.

bisonbleu’s picture

The translation_own_nodes module (#25) seems to be broken with drupal 6.26. The simple patch in #24 works.

thegreatone’s picture

Status: Closed (fixed) » Needs work

The last submitted patch, 68: translate-own-nodes-253157-68.patch, failed testing.

thegreatone’s picture

Issue summary: View changes

wich one should be used for D7? it's confusing..it started as D7 then switched to D8...
Entity translation...

bforchhammer’s picture

Status: Needs work » Closed (fixed)

Patch has been committed already(#74), setting back to fixed.

@thegreatone: this is against D8 core, I don't think there's an equivalent D7 version of this patch.

Gábor Hojtsy’s picture

The D7 issue for this is at #1829630: Improve workflow permissions (match D8 solution). It is in a contributed module, so its not this same issue reused. As pointed out above there is also a mini module at https://drupal.org/project/translation_own_nodes that implements some of this at least.

joshua.boltz’s picture

Anyone know if there is a custom solution that handles mlecha's issue. Or any ideas on how to hook into Drupal?

I need a user to be able to create a translation of a node but not be able to create any new node.

pieterdt’s picture

Component: translation.module » ajax system
Status: Closed (fixed) » Active

reopening, as this seems to be be gone from D8.1?

mallezie’s picture

Version: 8.0.x-dev » 8.3.x-dev
Component: ajax system » content_translation.module

This indeed looks gone to me as well.

RobertoGuzman’s picture

does these patches apply to Drupal 8.2.1 ?

lomasr’s picture

FileSize
80.52 KB

Tried to apply patch in #63 on drupal 8.3.x. But it gives me 'No such file or directory' error . Please see the screenshot. Is it applicable for 8.3.x ?

  • Dries committed 6ee939e on 8.4.x
    Issue #253157 by Maxtorete, j.somers, FiNeX, 5ven, fastangel, jibran,...

  • Dries committed 6ee939e on 8.4.x
    Issue #253157 by Maxtorete, j.somers, FiNeX, 5ven, fastangel, jibran,...

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

bahuma20’s picture

Here a little food for thought:

Is it possible to handle this via an additional operation in hook_node_access_records (grant_translation)? So that we could handle a scenario where a user should only be able to translate specific nodes, but not edit them.

s-jack’s picture

Sorry about my post, as not a developer.

Is this issue a low priority?
Spend a long long time.
The ability to restrict others from translating your posts is important.
I'm eager for progress.

Thank you for the development.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

weynhamz’s picture

Is it possible to handle this via an additional operation in hook_node_access_records (grant_translation)? So that we could handle a scenario where a user should only be able to translate specific nodes, but not edit them.

I like this idea, I am working on a project in which the access is set on a per-node basis, while translation form ignores the entity_access checks and there is no way to add the access check for translation, which causes a permission bypass.

  • Dries committed 6ee939e on 9.1.x
    Issue #253157 by Maxtorete, j.somers, FiNeX, 5ven, fastangel, jibran,...

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Berdir’s picture

Status: Active » Closed (outdated)

I'm not sure what exactly happened here either, but #2972308: Allow users to translate content they can edit finally happened and I think covers this and more use cases. Closing, not sure what status to use exactly.