Hi, I've recently come across the need to be able to dynamically set the content access permissions for a node.

My use case:

When an article is created I want the per-node content access permissions for that node set to match the selected roles from a rolereference field I have added to the article content type. So I need a rule that is able to set the 'view' permissions for that node to match the selected roles when the article is created. I have another rule that shoots off email notifications to people when new articles are created so the access permissions must be set before this happens.

Anyway, I can see many potential uses for such a rule. For example, you could dynamically set the view permissions to match the author's roles so that anyone with the same roles as them can view it, but nobody outside those role groups....

I created a patch to add these new rules in, and just for added bonus decided to add a revoke by operation rule as well. Here are some notes that may help documentation. I would be happy to update documentation as well if you do end up applying this patch. Which I really hope you do.

How they work

2 new rules:

  1. Grant access by operation
  2. Revoke access by operation

For both of these rules you set the following:

  • node
  • operation for which you want to alter permissions for
  • list of roles
  • reset

Each of these parameters may be set dynamically, however there are still restrictions. For example only a valid operation text string will be accepted for the 'operation' parameter. Possible values are (view, view_own, update, update_own, delete, delete_own). The list of roles is simply a list<integer>, but only valid roles can be chosen and all others will be ignored; roles with proper 'access content' permissions will be accepted; roles with the 'administer nodes' permissions will also be ignored since they are already allowed to perform such operations.

Comments

acrazyanimal’s picture

acrazyanimal’s picture

Anyone looked at this yet?

mgifford’s picture

No longer applies to git master branch:

$ git apply content_access-added-rules-actions-1464948-1.patch
content_access-added-rules-actions-1464948-1.patch:18: trailing whitespace.
content_access-added-rules-actions-1464948-1.patch:36: trailing whitespace.
error: content_access_rules/content_access_rules.rules.inc: No such file or directory

kaizerking’s picture

nice approach
But why to limit only to role reference? why not also user reference?
So that user referred will dynamically get access permissions through rules.
any entity referred should have this dynamic access
does that make sense?

kaizerking’s picture

Issue summary: View changes

wrote 'rest' instead of reset.

gisle’s picture

Status: Needs review » Closed (outdated)

This issue has not received any updates in the previous 8 years. If you believe it to still be relevant, you are encouraged to create a reroll of the patch for the HEAD of 7.x-1.x, reopen the issue and update it.

If you got an email about this Issue status update, it is because you at one time (possibly a very long time ago), subscribed to it. To learn how to unsubscribe yourself, please visit: https://www.drupal.org/project/webmasters/issues/3142987