Answered Making Remove Deleted Resources Context Aware

I know how to turn off the empty recycle bin in an Access policy, but when running a MODX install that has several contexts, is there a way to make this feature available to users that doesn't then go and permanently delete other resources in other contexts that have a status of deleted?

I was going to say there was no way of doing it, but then I did a little digging. It might be possible. The catch would be how to identify the context you *want* to delete from. I can't think of any way to do that. If you get the current context, it will always be 'mgr', which is no help.

If you knew the context, MODX fires OnBeforeEmptyTrash() just before it removes the deleted resources. It sends a reference ($resources) to the array of resources to be removed. In a plugin attached to that event, it should be relatively easy to loop through them, check the context_key field, and remove from the array and resources that don't have the target context_key.

Possibly, you could also check to see what contexts the user has access to and remove resources on that basis if that would help.

But wait . . . it just now occurs to me that the code that removes resources calls $resource->checkPolicy('delete'), so no use can remove resources he or she doesn't have the right to delete. As long as the users don't have delete permission for another context, what you're worrying about should never occur (and all my ruminations were unnecessary).

My test was to have a user without access to one context (web) but with access to another context (i'll call it other).

I logged into the web context as an admin and deleted a resource in that context but did not trash it. In another browser, I logged in as the user who has access only to the other context and deleted and resource. Then I clicked the trashcan icon. I checked both contexts. All the documents marked as deleted were deleted.

I will double check the permissions however.

Make sure that both contexts are protected. That would mean that some group the user is not a member of has a Context Access ACL entry that gives them access to the context. That should prevent the user from being able to remove docs in the other context.

The user in the "other" context belongs to a user group "Other" that only has access to the "other" context, not the web context, so they don't even see the web context, which is what we want. They also have access to the Manager context to allow them to edit pages and perhaps this is the issue. Don't you have to tie an Access Policy to the Manager that restricts them from doing certain things but also allows them to edit pages?

I think I see what's happening. The Context Access ACLs don't effect this. That's because 'delete' (the permission that's checked) is an Object permission that's part of an Object Policy like the Resource Policy.

What all that means is that to protect cross-context resources, they need to be in separate Resource Groups and protected by Resource Group Access ACL entries. All Users in a each context need to be in a User Group that's connected to the Context's Resource group with a Resource Group Access ACL entry.

I hope that makes sense.

Yes, one would assume that a person with no access to a protected context would be unable to remove resources in that context.