Skip to content
Snippets Groups Projects

ACLs - Priorities not working for groups

    • Open Issue created by Tobias Voigt @Tobias_Voigt

    This issue is related to updates to CiviCRM's ACL functionality that had been implemented last year. In 2023, two new functions for ACL have been developed:

    • Negative ACLs (to be able to have "Allow" and "Deny" rules)
    • Weightings / Priotities for ACLs

    When testing the new ACL funtionalities today, I realized that there (still?) is an issue regarding the priorities when dealing with groups.

    Test setup:

    • Create a test user ("X") that does not have the right to view all contacts
    • Create two groups (Group A and Group B)
    • Create a test contact ("Y") that is a member of both groups

    Then create two ACLs:

    1. Role "Authenticated", Operation "View", Type "Group", Mode "Allow", Priority "1", Group "Group A"
    2. Role "Authenticated", Operation "View", Type "Group", Mode "Deny", Priority "2", Group "Group B"
    • Log in with the test user "X" and check if you're able to see the test contact "Y"

    Behaviour: I can see the test contact "Y", even though the higher priority rule (No. 2) should prevent me from seeing "Y".

    Expected Beaviour: I can't see test contact "Y". Even though rule No. 1 allows me to view "Y" (as a member of Group A), rule No. 2 denies me to view "Y" (as a member of Group B). Since rule No. 2 has the higher priority, I am not able to see "Y".

    Interestingly the priorities seem to work fine regarding sets of custom fields(!).

    I'd be happy to do more testing. A lot of people pitched in last year to finance the new ACL functionalities. Now it would be great to get rid of this last problem to be able to fully use this in a productive setting.

    As soon as this has been solved, I'd be also happy to write an update for the CiviCRM documentation describing the new functionalities. I really do believe that these functionalities could be very useful for a lot of people.

    Thanks and best regards!

    Tobias

    Edited
    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items ...

    • Activity

    • Tobias Voigt changed the description

      changed the description

    • jaapjansma added git:civicrm-core sig:bug triaged labels

      added git:civicrm-core sig:bug triaged labels

    • ReginaSommerfeld
      ReginaSommerfeld @ReginaSommerfeld ·

      Thanks Tobias! We need this feature working for groups urgently.

    • colemanw
      colemanw @colemanw ·
      Owner

      @Tobias_Voigt @ReginaSommerfeld can one of you please review the pull-request that Seamus has written to verify it fixes this issue for you?

    • Tobias Voigt
      Tobias Voigt @Tobias_Voigt ·
      Author

      @seamuslee @colemanw @eileen @ReginaSommerfeld

      Thank you so much for reacting so quickly! I tested the PR (#5375) and I have good news and not-so-good news... ;)

      The good news: The PR works for the test scenario I described in this issue. That's awesome!

      The bad news: This only seems to have fixed one side of the problem. Now using ACLs to regulate access to contacts with priorities works - but only as long as we're dealing with a certain role. Once we introduce more than one role to the scenario the logic for the priorities doesn't seem to work.

      Here's the scenario in that I'm trying to get this to work...

      New test setup:

      • Create test users X and Y
      • Create a group 'Privileged Access' and assign only user Y to the group
      • Create an ACL role 'Privileged Access' and assign the group to the role
      • Create a test contact Z
      • Create a group 'Restricted Contacts' and assign contact Z to the group

      Then create 3 ACLs:

      1. Role "Authenticated", Operation "View", Type "Group", Mode "Allow", Priority "1", Group "All Groups"
      2. Role "Authenticated", Operation "View", Type "Group", Mode "Deny", Priority "2", Group "Restricted Contacts"
      3. Role "Privileged Access", Operation "View", Type "Group", Mode "Allow", Priority "3", Group "Restricted Contacts"

      Behaviour:

      • Test user X can't see contact Z
      • Test user Y can't see contact Z

      Expected behaviour:

      • Test user X can't see contact Z
      • Test user Y can see contact Z

      Even though rule No. 2 denies access to contact Z for all authenticated users - rule No. 3 allows access for user Y as a part of the group/role 'Privileged Access'. Since rule No. 3 has a higher priority than rule No. 2 it should outweigh the restriction set by rule No. 2.

      It seems to me that the roles somehow interfere with the priority logic here - but maybe that's not the issue here? In any case, it'd be so awesome to be able to use this feature in a productive setting with clients to regulate access in the way described in the new test scenario, because this was my original motivation behind my first issue regarding ACLs in 2023: To be able to grant privileged access to certain users for restricted contacts and custom fields - with 3 simple rules.

      Best regards

      Tobias

    • seamuslee
      seamuslee @seamuslee ·
      Owner

      @Tobias_Voigt can you check the latest commit I just put onto the PR I think that fixes the issue you found

    • Tobias Voigt
      Tobias Voigt @Tobias_Voigt ·
      Author

      @seamuslee thanks again for the superfast response!

      I think we're almost there. The effect I'm seeing now:

      • Test user X can't see contact Z
      • Test user Y can see contact Z (Yay!)

      But: Test user Y now can't see all other contacts, which should be allowed by rule No. 1. (Test user X can see all other contacts).

      Best regards

    Please register or sign in to reply