1 Reply Latest reply on Apr 27, 2013 7:29 PM by Sham HC

    Publish permissions

    cq5dev

      We have a project being migrated from CQ4 to CQ5.  We are trying to understand how people manage their permissions on the publisher.


      In CQ4, the permissions were associated with the user/group and replicated easily from author, so we could define the rules in author and just activate them.


      In CQ5, the permissions are associated with the content, but when you activate the page, the permissions are not replicated.


      Adobe says the reason for this is :

      "Page permissions are not replicated because they are stored under the nodes to which access is granted, not with the user.

      In general page permissions should not be replicated from the author to publish and are not by default. This is because access rights should be different in those two environments. Therefore it is recommended to configure ACLs on publish separately from author.
      "

      See http://helpx.adobe.com/cq/kb/PagePermissionsNotReplicatedWithUser.html


      However, they don't say how exactly one should "configure ACLs on publish separately from author"


      So what to do ?


      1) One way would seem to be to create a package of just the permissions and then manually install this package on each publish instance.

      Just activating the package would appear not to work

      This has the disadvantage that the sys admin has to log in directly to each publisher to install the packages, and it becomes a "deployment" task to change permissions


      2) Login to the publishers and apply the access rights directly on each publisher.

      This has similar problems to the one above, and might have timing issues, e.g. when a page is activated by a user


      3) we could use Closed User groups.

      Whilst this would seem to work for a limited extent, it seems the limitations might be too much for us.

      E.g. If we have a Closed User Group for the intranet, and then within the intranet we have a section for HR only, we would want 2 groups, one

      for "intranet-users" which would have access to

      /content/intranet/en

      and one for "intranet-hr-users". which would have access to

      /content/intranet/en/hr


      From what I can tell a member of "intranet-users" automatically gets access to everything underneath /content/intranet/en so would have access to all the HR content too


      Also with Closed User Groups, how do I get an overview of what permission a particular user or group has ? 



      4) There is a utility package to create packages based on an XPATH which might help with 1) but still has the same issue of direct deployment to publish.




      TBH, I am not sure really why the permissions cannot be replicated.

      Normally we would just assign users to groups and assign groups permission to read the pages, on publish users would not be members of the "authoring" groups so there wouldn't be a problem.


      Is there a workaround or hotfix ?



      Dev.