Problem/Motivation
NodeAccessControlHandler::acquireGrants() does not consider translations with different published states. It stores grants for whichever translation you are currently saving and applies it to all translations, regardless of their individual published states.
Steps to reproduce
1. Setup a translatable node type and make sure the published flag is also translatable.
2. Create a node and publish it
3. Create a translation for this node and save it as unpublished.
You can now observer that the original node, which is published, is not accessible.
Proposed resolution
Extend NodeAccessControlHandler::acquireGrants() function to include grants on a per translation basis instead of only the translation being saved.
Remaining tasks
Review attached patch
User interface changes
None
API changes
None
Data model changes
None
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | 3162934-15.patch | 1.4 KB | lobsterr |
| #8 | 3162934-nr-bot.txt | 143 bytes | needs-review-queue-bot |
| #2 | 3162934-2.patch | 1.39 KB | weseze |
| support-for-grants-on-translatable-published-flag.patch | 1.37 KB | weseze |
Comments
Comment #2
weseze commentedSmall correction so it only respons to empty grants array.
Comment #5
crzdev commentedThanks @weseze, similar related problem detected using grants to restrict private content access using content translations (translatable status "Published"), revisions & content moderation with draft content.
Prior applying this issue related patch. problem was related to not accesible content (public content with empty grants at time acquireGrants is executed; so default core behaviour occurs) when saving not published translation of content with some other published translations.
In that case, node_access table results into empy rows for saved nid.
Patch seems working but another problem appears when saving new translation (with an user without bypass node access permission), form validation error: "Either the path '/node/..' is invalid or you do not have access to it." . Used patch from https://www.drupal.org/project/drupal/issues/3101344#comment-13461721 to solve & seems everything works as expected now, any case, still having some doubts about this, seems to be a major core problem when using the above-mentioned suite of functionalities.
This use case is added in order to clarify, if possible, a bit wich should be the expected core behaviour using this complete suite of functionalities.
Edit: /admin/content not showing draft content without enabling "Disable SQL rewriting"
Comment #8
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #10
dioni commentedHi,
I had this issue today with drupal 10.3.10, and the patch worked as expected.
Related patch https://www.drupal.org/project/drupal/issues/3101344#comment-13461721 has been included in core, so we don't need to apply it.
Comment #11
smustgrave commentedPatch should be in an MR pointed at 11.x
As a bug will also need some test coverage.
Comment #12
acbramley commentedI am not able to reproduce this issue with the steps provided. Can they be expanded to start from installing Drupal core?
Comment #13
weseze commentedAlso can not reproduce this anymore.
I think it was related to one of the many contribs we are using to provide access controle to nodes. Or it has been fixed in core in another way.
For anyone interested, in views this is still a problem: https://www.drupal.org/project/drupal/issues/3061782
Comment #14
eduardo morales albertiOn our case we still need the patch. We have behat coverage and after upgrade to Drupal 11.2.3 the patch #2 did not applied and the multilanguage tests failed because the published states.
We use the hook node grants to alter those permissions, so it is important for us to respect the translations grants.
Comment #15
lobsterr commentedWe still experience this issue:
Patch for Drupal 10.6.x
Comment #16
acbramley commented@lobsterr are you able to provide the steps to reproduce this? As per #12 and #13 we were unable to.
Comment #17
lobsterr commented@acbramley let me try to do it on the clean instance