2.05 upgrade notes on Access Policies and Templates

Just a few notes after spending a lot of time on the upgrade from 2.04 to 2.05:

If any custom permissions have been added to the Administrator policy in 2.04, they will be completely deleted in the upgrade process to 2.05 when that policy becomes the Administrator template. It might be good to add a more specific mention of this to the documentation at http://rtfm.modx.com/display/revolution20/Upgrading+to+Revolution+2.0.5.

Fortunately I documented the ones I had added and it was easy to re-create them. A minor point: I created several new policies that used the Administrator template. Then I added my custom permissions to the Administrator template. After that, on the Access Policies tab list, the numbers in the Active Permissions column are always wrong--reporting "137 of 141" when it should be more like "86 of 141".

It would also be very helpful to include a list of any new permissions added to the default templates at the release of each upgrade. That’s important because we need to evaluate whether a new permission should be activated in our other policies. Without this I wind up doing a manual comparison check to see what’s changed.

And I’ve said it before, but it bears repeating: the permission "access_permissions" is too generic and used in way too many places. For instance, as I will note in another posting most Form Customization rules will fail if the user group does not have the access_permission right. And if that right is granted it gives the user access to pretty much everything under Access Controls--user groups, roles, access policies, and policy templates. Even if the menu option is removed, the action is still available; that’s not a minor security concern.

So I have had to make core edits to apply new, more specific permissions for access controls, document groups, resource groups, and user groups to tighten up security. Since there were default permissions in the system specific to form customization, messaging, user profiles, roles, and users it seems odd that specific permissions weren’t created for these other areas as well.

I hope these notes are helpful to both the core team and other users.

Quote from: SBM at Dec 15, 2010, 02:54 PM

If any custom permissions have been added to the Administrator policy in 2.04, they will be completely deleted in the upgrade process to 2.05 when that policy becomes the Administrator template. It might be good to add a more specific mention of this to the documentation at http://rtfm.modx.com/display/revolution20/Upgrading+to+Revolution+2.0.5.
Fortunately I documented the ones I had added and it was easy to re-create them. A minor point: I created several new policies that used the Administrator template. Then I added my custom permissions to the Administrator template. After that, on the Access Policies tab list, the numbers in the Active Permissions column are always wrong--reporting "137 of 141" when it should be more like "86 of 141".

Not sure what’s going on in the reporting #s. But a note: You should *not* be adjusting the Administrator template with new permissions if you expect that to survive upgrades. Duplicate it, or add your new permissions into a new Template, and create ACLs with that new AP Template.

It would also be very helpful to include a list of any new permissions added to the default templates at the release of each upgrade. That’s important because we need to evaluate whether a new permission should be activated in our other policies. Without this I wind up doing a manual comparison check to see what’s changed.

Duly noted. Thanks!

And I’ve said it before, but it bears repeating: the permission "access_permissions" is too generic and used in way too many places. For instance, as I will note in another posting most Form Customization rules will fail if the user group does not have the access_permission right. And if that right is granted it gives the user access to pretty much everything under Access Controls--user groups, roles, access policies, and policy templates. Even if the menu option is removed, the action is still available; that’s not a minor security concern.

100% agree; this will be on the list for 2.2 (2.1 is coming soon and has a very short-list of features). Can you file an issue for this so it doesn’t get overlooked? http://bugs.modx.com/

So I have had to make core edits to apply new, more specific permissions for access controls, document groups, resource groups, and user groups to tighten up security. Since there were default permissions in the system specific to form customization, messaging, user profiles, roles, and users it seems odd that specific permissions weren’t created for these other areas as well.

It was mostly a not-enough-time, need-to-get-2.0.0-out issue. That, and no one filed issues for them.

I hope these notes are helpful to both the core team and other users.

They were! Thanks!

Related - am I being dense or can we no longer create permissions through the manager? I was looking to add a custom permission to a policy template, but when I type in the ’new’ permission it runs an ajax query and auto-populates from modx_access_permissions - overwriting the new permission I want to add. I can manually add a permission to the database, but in 2.0.4 there was ’New permission’ under Access Policies - which seems to no longer exist under the Policy Template way of creating Access policies. Or have I missed something?

It works for me. You have to type in the new permission name without activating the drop-down list.

@Shaun,

Wouldn’t it make sense in 2.0.6 to require access_permissions for creating or updating FC rules, but not for executing existing ones?

@BobRay - in Firefox 3.6.12 I trigger the dropdown when I type more than two letters into the ’name’ box. If I’m quick I can save it - but then the name shows up as blank (ie the value from the dropdown overrides). Similar, but not the same, problem to one I was having with the dropdown box for files in selecting / deleting images.

Quote from: odeclas at Dec 15, 2010, 04:40 PM

@BobRay - in Firefox 3.6.12 I trigger the dropdown when I type more than two letters into the ’name’ box. If I’m quick I can save it - but then the name shows up as blank (ie the value from the dropdown overrides). Similar, but not the same, problem to one I was having with the dropdown box for files in selecting / deleting images.

This seems to be an ExtJS bug; after typing in the name, try clicking outside the dropdown for now. It’s been fixed here: https://github.com/modxcms/revolution/commit/ae53edbbde55e1b17a42408bd5a007e16434d933

Curious. It worked fine for me in FF 3.6.12. Maybe FireBug prevented the bug -- that would be ironic.