"Modify" permission not inherited from folder to asset | Community
Skip to main content
V
volkers57834491
December 30, 2015
Solved

"Modify" permission not inherited from folder to asset

  • December 30, 2015
  • 9 replies
  • 3366 views

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

    This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
    Best answer by Lokesh_Shivalingaiah

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

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

    9 replies

    edubey
    edubey
    Level 10
    December 30, 2015

    Hi, 

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

    V
    volkers57834491Author
    December 30, 2015

    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
    edubey
    Level 10
    December 30, 2015

    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
    Lokesh_ShivalingaiahAccepted solution
    Level 10
    December 30, 2015

    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-007
    GK-007
    Level 9
    December 31, 2015

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

    And also post the results.

    Thanks,

    Kishore

    V
    volkers57834491Author
    January 4, 2016

    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

    V
    volkers57834491Author
    January 13, 2016
    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
    s_thurgood
    February 7, 2017

    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
    Ashokkumar_TA
    Level 2
    February 8, 2017

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

    Terms & ConditionsAccessibility statement

    Loading footer...