Contrib.social

Translation tab has problems with unpublished nodes when using modules that implement hook_node_grants

Open on Drupal.org →
Created on 6 July 2012, over 12 years ago
Updated 22 February 2023, over 1 year ago

"unpublished nodes" don't show up on node/%node/translate for users where uid ≠ 0 as soon as modules are installed that implement hook_node_grants
I spent quite a while looking into what causes this issue, and succesfully reproduced it on a clean install of 7.14 and 7.x-dev.
These are the steps to reproduce:

- perform a fresh install of Drupal 7.14
- Enable locale and content_translation modules

- Give "authenticated user" the following permissions:
-- create/edit own/delete own content for Basic Page
-- translate content
-- view own published content

- For the basic page content type, enable Multilingual support: " Enabled, with translation"

- in "Regional and languages", add a language (I added Dutch (NL))

- Create a new user johndoe

- Log in as johndoe

- Create a basic page in the default language (EN)
- Go to the translate tab of that page and add a Dutch translation
- Go to the translate tab from the translation. Remember what you see.

- Log back in as admin

- Unpublish the original node (node/1)

- Log back in as johndoe

- Check the translate tab on node/1/translate and node/2/translate. Everything looks normal.

- Logged in as admin again, enable any module that implements hook_node_grants (e.g.: content_access, og_access, nodeaccess_userreference, ..)

- Rebuild node access

- Log back in as johndoe

- Check the translate tab on node/1/translate and node/2/translate. What the @é$%! Why does English appear "not translated" ?
=> THE PROBLEM: our unpublished translations won't appear any more

- Disable any modules that implement hook_node_grants, recheck the page.. Everything back to normal.

A little background info (from my point of view, might be completely wrong)
in translation.module, translation_node_get_translations() adds a node_access tag.
This will be handled in node.module by _node_query_node_access_alter(). Here the simple query get extra conditions added . This is no problem at all, but one of the last lines of code $subquery->where("$nalias.$field = na.nid"); seems to suggest that a node must always have an entry in the node_access table, which seems not to be the case?

🐛 Bug report
Status

Needs work

Version

7.0 ⚰️

Component
Content translation  →

Last updated about 18 hours ago

No maintainer
Created by

🇧🇪Belgium rv0

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment over 1 year ago →
    🇳🇿New Zealand quietone

    This was a bugsmash daily target yestersay. Lendude responded saying that they are currently "working on a site that uses node grants a LOT and also uses translations for all content types, this is not an issue". That sites does "use content moderation, so ‘unpublished’ becomes a bit more vague". They looked at the D7 and D8 code and determined that this is a “different nid for a translation” problem. And concluding this issue belongs in Drupal 7.

    They also pointed out that the problem in #15, is a different problem and perhaps needs a separate issue. For that, I tested on Drupal 10.1.x, standard install. I was not able to follow the second step. "content editor 1 creates a node (in default language) and saves it as unpublished'. The content editor does not have permission to set the content as unpublished.

    This is summarized into two problems in that comment.

    • problem 1: non admin user cannot translate unpublished content
    • problem 2: non admin user cannot translate a node if the source node is unpublished

    And I found that not to be true. A non admin user can translate unpublished content if it is their own content. And I deleted the first language and the author, a content editor, was able to add a translation in the second language without error.

    All together, I think this is working as designed. If I am wrong, open a new issue and provide steps to reproduce.

    I am moving this to Drupal 7.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024