Permission group override indicator can be misleading

[Susan Morrison]

Bug https://bugs.launchpad.net/evergreen/+bug/1891375 introduced a feature where, when a permission group has the same permission inherited by the parent group and then locally assigned to the child group, an override symbol appears next to the child group's permission to indicate which permission rules are being followed. In testing, I've found that whether the permission is inherited or assigned locally does not factor into which permission overrides the other but instead follows the general rules of:

- Depth is looked at first in ascending order (0 to 3), so broadest depth wins
- Grantability is looked at in descending order (1 or 0) so true will override false, but only when depth is assigned at the same level

I know in most (if not all) cases, the child group would have the permission assigned at the broader depth, so it generally won't be an issue, but I think the override symbol should be based on the depth of the permission instead of how it is assigned to the group.

A couple examples:

Permission for PATRON_EXCEEDS_FINES.override is assigned to the following:
- Administrator (parent): depth=0, grantable=true
- Local Admin (child): depth=1, grantable=false

Using a Local Admin account, I had the ability to override the patron exceeds fines exception for any patron in the consortium, and I could grant the permission to staff accounts. In the permissions list, the Local Admin permission is shown to override the inherited Administrator permission, but the permission was following the rules assigned at the Administrator level.

Permission for ADMIN_BOOKING_RESOURCE is assigned to the following:
- Administrator (parent): depth=1, grantable=false
- Library Manager (child): depth=2, grantable=true

Using a Library Manager account, I could create a booking resource for any branch in the system and was not able to grant the permission to other staff. In the permissions list, the Library Manager permission is shown to override the inherited Administrator permission, but the permission was following the rules assigned at the Administrator level. Screenshots attached.