In EntityAccessManager->access(), the current implementation assumes that access should be granted if any requirement is met (OR logic).
Some sites may want to configure it to pass only if all requirements are met (AND logic).
Attached patch provides a lightweight way to do via config, ex:
// in settings.php
$config['dea.settings']['access_check_boolean_operator'] = "AND";
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | dea-and_logic_for_access_management-2893901-2.patch | 2.89 KB | renaudcuny |
Comments
Comment #2
renaudcuny commentedComment #3
gnindl commentedApart from the global setting (alternatively to be put in a configuration object) I would see the configurable logic operator per entity operation field instance.
Comment #4
pmelab commentedWhats the use case of this? You've got a set of privileges granted to group "A" and a set granted to group "B". And now you want a new set of privileges that is granted to users that are part of group "A" and "B"? This sounds like you need a group "C" with new privileges.
Drupal permissions work based on the "At least one grant and no deny"-rule. I would rather not move away from that.
Comment #5
renaudcuny commentedThe use case is as follow:
Vocabulary 1 defines a property of the node, ex: Type of Article:
- News article
- Biography
- Interview
Vocabulary 2 defines a subset of users, ex: Department/Unit:
- Marketing team
- Press team
- Legal department
- Web team
You want to use DEA to set limitations in this way:
- Marketing team can edit only News article and Biography
- Press team & Legal only Interview
- Web team can edit them all
Comment #6
pmelab commentedThats how I thought about this kind of problem when implementing it (yes, this would be a single vocabulary):
Comment #7
gnindl commentedIf DEA should support multiple access group (field) checks per entity - nothing prevents you to configure that - then the AND operator between fields is the only way to implement the policy "At least one grant and no deny". The current implementation realizes the OR operator "At least one grant, ignore deny". If you only test the entity again one access group, you do not notice that, however, when scaled the difference in logic becomes visible.
Being a bit less philosophical, I alter renaudcuny's example a little bit (you could also use user roles here, but just for illustration):
The current implementation (OR operator) violates 2 as permission would have already been granted on 1 as implemented here:
From my perspective, the second check is simply ignored, correct me if I am wrong.
Comment #9
gnindl commentedMerged and committed to development branch.