A new grant access is not allowed until after a manual permission rebuild

Created on 10 April 2023, over 1 year ago
Updated 26 June 2024, 16 days ago


After granting a role to a node, the content is not viewable by the role without first running

reports | status report - rebuild node permissions

Steps to reproduce

  • Add a new Start Event - Specify a Content Type
  • Connect a new Task to the Start Event - Content Access Grant Access, specify a role

Proposed resolution

πŸ“Œ Task






Created by

πŸ‡ΊπŸ‡ΈUnited States hedrickbt

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

Comments & Activities

  • Issue created by @hedrickbt
  • πŸ‡©πŸ‡ͺGermany jurgenhaas Gottmadingen

    I'd say this is by design. It's the nature of the node access architecture. Calling the rebuild node permission process can be very "expensive" when a site has a huge number of nodes. Calling it every time, a model gets saved that does something with node access, is probably not a good idea. Especially because it is not trivial - or even impossible - to find out if any change is affecting the permissions and requires the rebuild.

    Calling the rebuild manually is recommended, and we should document that in the ECA Guide. Or is there any other recommendation of what could be done to improve this? At least, this is not really a bug.

  • πŸ‡ΊπŸ‡ΈUnited States hedrickbt


    Thank you for your consideration. Would it make sense to add the same code to

    modules/contrib/eca_content_access/src/Plugin/Action/GrantAccess.php -> execute()

    that exists in modules/contrib/content_access/src/Form/ContentAccessPageForm.php -> submitForm()

    $this->grantStorage->write($node, $grants); // this line already exists, what follows is that would be added

    foreach (Cache::getBins() as $cache_backend) {
    // xxxx
    // route: node.configure_rebuild_confirm:
    // path: '/admin/reports/status/rebuild'.
    $this->messenger()->addMessage($this->t('Your changes have been saved. You may have to rebuild permissions for your changes to take effect.',
    [':rebuild' => Url::fromRoute('node.configure_rebuild_confirm')->toString()]));

  • πŸ‡©πŸ‡ͺGermany jurgenhaas Gottmadingen

    @hedrickbt I've had another look at that code, and I'm not confident that this is the right approach. There are 2 reasons:

    • They are deleting all caches after storing the settings. Not only do I think this is unnecessary as a rebuild permission should be sufficient, it's also a potential for large sites, that avoid to flushing their caches at all cost.
    • They then display a message with a link to rebuild permissions. That makes sense in the context of the settings form, as that's an interactive session by a permitted user. In the context of an ECA model, that action can be executed by any user, i.e. someone who has performed a certain task to gain extra permissions, but you don't want to show them a message to a backend link for rebuilding permissions.

    However, what we could implement into this action are a couple of options:

    • Flush cache: defaults to FALSE
    • Further action options: defaults to none
      • None: no further action
      • Display message: display the same message that the content access module does
      • Redirect to Rebuild Permissions: redirect to the page directly instead of showing the link

    That way, the user who configures the ECA model has the choice and can tailor it towards their use case.

  • πŸ‡©πŸ‡ͺGermany jurgenhaas Gottmadingen
  • Status changed to Needs review 2 months ago
  • πŸ‡©πŸ‡ͺGermany jurgenhaas Gottmadingen

    We've now implemented most part of the suggested solution in #4, but the direct rebuild is not implemented yet because core committers advised against it. We need to follow up with the content_access maintainers to see if there is a better way to do the per node access control, because rebuilding access can be VERY expensive.

  • Status changed to Fixed about 1 month ago
  • πŸ‡©πŸ‡ͺGermany jurgenhaas Gottmadingen

    Marking as fixed for now as we publish the first release candidate today and there doesn't seem to be a good solution for the second part either. Should that still be an issue, we need to get another issue opened for explicitly that part.

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

Production build 0.69.0 2024