As I’ve fumbled around with custom access policies off and on over the past year, I’ve occasionally been frustrated when new permissions appear and old ones disappear with new version upgrades.
The basic instructions for creating a custom access policy are "duplicate the admin policy, and then remove the permissions you don’t want in your custom policy". This works initially, but when subsequent Revo upgrades then add or remove permissions to the administrator policy, things can get out of sync. Two things can happen:
- Custom policies can contain permissions that have been removed from the master list (like ’add_children’).
- Custom policies can be lacking a new permission that you’d want them to have... suddenly the user can no longer do some action they used to be able to.
I’ve had both of these happen. I haven’t been keeping good records, so I don’t have a lot of specific examples. But it seems like the more you customize your policies, the bigger a problem this can become.
Since the master list of permissions changes from version to version, it seems like at a minimum there needs to be a set of housekeeping procedures required for maintaining the health of custom access policies during version upgrades. Here are the necessary components of that process as I see them:
- A readily available master list of all permissions and what functions require them
- A "diff" style comparison sheet for each Revo version release, that makes it easier to see which permissions were added or removed
With that info in hand, a MODx administrator could at least be empowered to manually inspect each custom access policy and decide whether or not to add new permissions or delete obsolete permissions.
Thoughts?
☆ A M B ☆