[SOLVED] [BUG #6934] ACLs - How to give remove permission to a user group to delete only specific resources?

What I'm trying to achieve is to give permission to a specific user group to delete some resources but not others.

I found two perspectives but none yields the intended results:

1- Grant the user group "delete_document" permissions (Access Policy+Context Access ACL), and restrict the remove permission via the Resource Group Access ACL ("Load, List and View" policy for the mgr context and appropriate resource group). Result is Context Access ACL permissions overwrite Resource Group Access ACL and the user can always delete resources in the resource group.

2- Do the opposite, ie uncheck "delete_document" permissions in the Access Policy for the user group, grant the remove permission via the Resource Group Access ACL ("Object" or "Resource" policy for the mgr context). Result is, the user group is nerver granted remove permissions on resources in the resource group.

Hope it's clear.
Did I miss something or is it an impossible case scenario in modx?

Revo 2.2.0-pl2 [ed. note: yogooo last edited this post 12 years, 1 month ago.]

In theory, #1 should do it. #2 can't work because without the "master" Context Access permission, you can't perform the action ever.

In order to delete a resource in a protected resource group, a user needs both the Context Access permission and the Resource Group Access permission to do so.

It may be that the resource group is not seen as "protected" because it's not connected to any other user groups. Try #1 + connecting the resource group to the Administrator group in a Resource Group Access ACL entry with a policy of "resource".



---------------------------------------------------------------------------------------------------------------
PLEASE, PLEASE specify the version of MODX you are using . . . PLEASE!
MODx info for everyone: http://bobsguides.com/MODx.html

Hi Bob, thanks for you reply and great guides!
I tried your suggestion and flushed permissions and sessions to no avail, delete permission is still being granted.

What's surprising is that when changing the Resource Group Access policy, say from "resource" to "load, list, view", the save permission is respected. Only the delete permission seem to escape control.

Did you ever see it work ? Could this be a bug?

There's another oddity in the CRUD permissions. In the Administrator Policy Template there are "basic" 'save' and 'create' permissions on top of the specific ones (save_document, new_document,...) but there's no "basic" 'delete' or 'edit' permissions, only the specific ones (delete_document, delete_chunk,...., edit_document,...).

Is it unrelated or could it be that the 'delete' and 'edit' permissions exist, that the ACL are expecting them to be set, and that they have not been added to the Administrator Policy Template? As far as I understand ACLs, this doesn't make sense as if it would be the case it would be impossible to get any delete permission at all... just want to make sure.

Revo 2.2.0-pl2

Hmm. . .I'm looking at 2.1.5, so this might not be relevant, but and I don't see any "delete" permission in the Resource policy template. Let me suggest something else to check. Try taking away the "remove" permission in the Resource Group Access ACL policy.

I'm thinking you may have a delete permission left over from an earlier version. I'm pretty sure "remove" is now the relevant permission and "delete" would be ignored. That would explain what you're seeing.

And, BTW, "remove" is the general permission in the Administrator policy as well.



---------------------------------------------------------------------------------------------------------------
PLEASE, PLEASE specify the version of MODX you are using . . . PLEASE!
MODx info for everyone: http://bobsguides.com/MODx.html

Try taking away the "remove" permission in the Resource Group Access ACL policy.

Hmmm, not working either. I posted http://www.haiku.hk/modx-acl/"" target="_blank" rel="nofollow">screenshots of my ACL setup, that might be easier and faster. Would you mind taking a look at it and let me know if you spot any error?

I'm thinking you may have a delete permission left over from an earlier version.

Nope, it's a clean install of revo 2.2.0-pl2 traditionnal.

I'm pretty sure "remove" is now the relevant permission and "delete" would be ignored.

Checked it and you're right, it's not a "delete" permission but a "remove", my bad.

Your book MTOG came in the mailbox I set up a new and clean Revo 2.2.0-pl2 traditional install and did the tutorial "Working with Modx Security" from p.454 to p.460.

In the tutorial, you write, p.459, §3, L2: « We need to use a policy that allows them [editors] to see the page [news] and its children in the tree but not to edit it, delete it, unpublish it, or do anything else with it. »

Yet, I get the exact same result as with my own experiments: Editors cannot edit/save the "News" resource, but *they can delete it* even thought permission was not granted by the "ResourceViewOnly" Resource Access Policy.

Any idea if the ACL system changed in 2.2. or is this a bug?
[ed. note: yogooo last edited this post 12 years, 3 months ago.]

That's really starting to sound like a bug. Can you report it here: http://bugs.modx.com/.


---------------------------------------------------------------------------------------------------------------
PLEASE, PLEASE specify the version of MODX you are using . . . PLEASE!
MODx info for everyone: http://bobsguides.com/MODx.html

Reported as http://bugs.modx.com/issues/6934"" target="_blank" rel="nofollow">bug #6934.
Update: Bug reference added to the thread's title.

Are we talking about:

a) delete = send to trash can
b) remove = remove record from database

?

The permission itself is named 'remove' in the various policies templates. The UI button on the resource editing page is labeled 'delete', id = modx-abtn-delete in the html.

However there's a twist revealed by your excellent question! To answer it, I had to click the 'delete' button on the resource editing page. Guess what, Modx asks for confirmation and upon confirming 'yes, send this to the trash can', it throws an error: 'permission denied'. The resource is indeed protected...

It never crossed my mind to click the 'delete' button because when the 'save' permission is revoked, Modx hides the 'save' button—which is an expected behavior. I assumed that if the 'delete' button is shown and active, the user has the appropriate permissions.

So it's more a problem of UI/UX design & consistency and certainly not an ACLs bug. As with the 'save' button, the 'delete' button should clearly not be displayed when the current user logged in doesn't have the appropriate permissions. Why display an action if the user can't perform it? Super misleading and frustrating UX design.

How do we proceed? Should I update and reclassify the bug report? Do we close it and I reopen a new one?

Update: I noticed that when the 'save' permission is revoked, all the form fields of a resource are still active when editing it. The user can make modifications but is not allowed to save them. I'd suggest disabling all fields to reflect the permissions and save some headaches to users and admins. [ed. note: yogooo last edited this post 12 years, 2 months ago.]