"Modify" permission not inherited from folder to asset

[volkers57834491]

Hi,

we want users of a specific group to be able to upload, modify and replicate assets in a specific folder in the DAM, but they shall not be able to delete assets from the folder. Therefore we assigned "Read", "Modify", "Create" and "Replicate" permissions to the folder but omitted the "Delete" permission. Problem: When the user uploads an asset the "Modify" permission is not inherited from the folder to the asset, so that the user cannot edit the assets properties (e.g. the title), see screenshot. We always have to assign the "Modify" permission manually to the asset afterwards (which is not an option). If we assign "Modify" AND "Delete" permissions to the folder they are both inherited to the asset. My question: Why is the "Modify" permission not inherited and what can we do to achieve that without assign the "Delete" permission also? Any help is greatly appreciated.

Environment: CQ 5.6.1, SP 2

Thanks, Volker

[edubey]

Hi, 

Are you able to replicate this permission issue in another environment? 

[volkers57834491]

Yes we have this issue on all our servers, local development servers as well as QA servers as well as production servers. It's also not a matter of a specific folder, the behaviour is the same for all folders.

[edubey]

We do faced similar issue where permission were not inherited properly however it was working fine once instance was restarted. I would recommend to raise a day care ticket for the same.

[Lokesh_Shivalingaiah · Accepted solution]

It should inherit ! This looks like a bug to me. Please raise a day care ticket here

https://daycare.day.com/public/contact.html

[GK-AEM]

Please set new CQ instance and create user and apply the same permissions and check it.

And also post the results.

Thanks,

Kishore

[volkers57834491]

Ok, I've set up a "naked" 5.6.1 GA instance without any hotfixes. The behaviour is the same. I then installed SP 2 over the GA release. This didn't change anything. I will raise a daycare ticket.

BR, Volker

[volkers57834491]

And here is the response from daycare: "The issue is due to the fact that Modify permissions is not inherited. Basically Read, Write are inherited but not modify. I did some research and I found that this is an expected behavior for CQ 5.x. It does not allow inherited modify if there is no delete permission (CQ5-34635). Just to let you know that this is not a case in AEM 6.0. The only possible workaround is to add delete; you can possibly grant an extra right to a dedicated user (image editor group)."

[s_thurgood]

This is also an issues in 6.2. We have a lot of assets in our company, and to manually go in and mark each asset for modify permissions is not a feasible workaround. And adding Delete permissions just to include modify opens up a lot of security / management problems. Why would this be expected behavior? I would assume that, as with the other permissions, if I check the modify box, that permission should be inherited all the way down the tree, including to the individual assets. Can this be fixed to perform in the same way that the other permissions perform?

[Ashokkumar_TA]

You can try to set permission with regex globbing pattern on the JCR node - on any node in the hierarchy.