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

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.

@jurgenhaas,

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) {
$cache_backend->deleteAll();
}
// 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()]));

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

jurgenhaas → credited srbracelin → .

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.

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.