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

Comments

weseze created an issue. See original summary.

weseze’s picture

StatusFileSize
new1.39 KB

Small correction so it only respons to empty grants array.

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

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev
crzdev’s picture

Thanks @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"

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

needs-review-queue-bot’s picture

Status: Needs review » Needs work
StatusFileSize
new143 bytes

The 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.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

dioni’s picture

Status: Needs work » Needs review

Hi,

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.

smustgrave’s picture

Status: Needs review » Needs work
Issue tags: +Needs Review Queue Initiative, +Needs tests

Patch should be in an MR pointed at 11.x
As a bug will also need some test coverage.

acbramley’s picture

Status: Needs work » Postponed (maintainer needs more info)
Issue tags: +Needs steps to reproduce

I am not able to reproduce this issue with the steps provided. Can they be expanded to start from installing Drupal core?

weseze’s picture

Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

Also 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

eduardo morales alberti’s picture

On 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.

lobsterr’s picture

Status: Closed (cannot reproduce) » Needs work
StatusFileSize
new1.4 KB

We still experience this issue:

Patch for Drupal 10.6.x

acbramley’s picture

Version: 11.x-dev » main
Status: Needs work » Postponed (maintainer needs more info)

@lobsterr are you able to provide the steps to reproduce this? As per #12 and #13 we were unable to.

lobsterr’s picture

@acbramley let me try to do it on the clean instance