3 Replies Latest reply: Mar 23, 2012 12:33 AM by Greig RSS

    UPK11 - multi-user environment - manage author permissions - help

      We are configuring our UPK 11 multi-user environment.
      As we have it set, the "everyone" group has modify access to all folders.

      I would like to have a few admins have modify access to the system folder and everyone else be read only.

      Here's my dilemma -
      My admin profile is also a part of the everyone group - so if I set the permissions on the everyone group to read only, that effects the admin login as well.

      The documentation says that if I set up an author with explicit folder permissions, that they are not included in the everyone group, but everytime I try, they are added (irrevocably) to the everyone group before I can even assign an explicit permission.

      I tried to set the everyone group to read only and nearly hobbled my admin account.

      Can someone who has managed authors in a UPK 11 multii-user environment send out some tips?
      I'm not understanding the documentation well enough to make headway.

        • 1. Re: UPK11 - multi-user environment - manage author permissions - help
          Hi Paul,

          I recently performed an implementation of UPK 11 at a client and had to show one of their employees how to administer the security surrounding profiles and authors.
          The group "Everyone" is default, and each person will belong to that group. It seems that when a person is assigned to another group/with author-specific permissions, it will override that which is set to the "Everyone" group.

          What I normally suggest (and implement) is that you modularise your security (separate the authors into their respective departments), and then create those departments as groups, and then assign permissions as required. Lets use an example - it assumes you are logged in as an admin user:

          I create 3 folders (where 4 and 5 are defaults):
          1. HR
          2. FIN
          3. CS
          4. Administrators
          5. Everyone

          Each author is defaulted to number 5, and all administrators should be included in group 4.
          Now the goal is to prevent HR and FIN from modifying CS, and vice-versa for the other two groups.

          You will see in your library that the root is defined as "/". Firstly, ensure that the Administrators group has Modify access to this folder (Administration --> Manage Groups --> Permissions). I think you need to click on edit, then click on the "Add" button (under permissions), and choose the root folder "/" - ensure it has modify - by default this value should already exist. This now ensures that the security is filtered down to all sub-ordinate folders that exist under the root folder - you do not need to manually assign "modify" permissions to each folder for the Administrator group, as you have already done so at root level.
          You will also notice that there is a "Members/Users" tab (can't remember off the top of my head which), and this allows you to select the profiles/authors that have Administrator group priviledges - ensure the correct users are selected.

          I normally leave the "Everyone" group as it is - do this for now, ensure everyone is included in it, and only modify after you have implemented and tested your security structure if needs be - normally the other group permissions override the "Everyone" group permissions.

          Next step is to assign department specific permissions to the 3 folders we created. Navigate to Administration --> Manage Groups, and ensure that you begin by editing the first department group (HR) - create the group if not already done, then edit (little pencil logo). You would like all HR users to have full modify access to their folder only, but they must not be able to mess around with the other two departments or the "System", "Getting started with UPK" and "/" folders. Under permissions, click on the Add button, and ensure that the folder "HR" has modify priviledge. Add the remaining 4 folders (CS, FIN, System, Getting started with UPK), and assign either Read or Read/View permission - this will ensure all other folders cannot be modified by HR users. Add the relevant HR users to the group under the "Members/Users" tab.

          Apply the same for FIN and CS respectively.

          Now you could get to a point where you may need cross-departmental access for a few users (FIN may need to access some HR content). I recommed that you do this on the user level, and not the group level, as you will limit who can access other departments. Navigate to Administration --> Manage Authors. Click on the specific user that will require access to another department. Edit his profile and under the permissions tab, ensure that he has required access to the other department folder (or sub-folders only) by adding and assigning the priveledge. This should ovveride the group security set for that specific department - but only for this user!

          Test by attempting to create content in an un-authorised folder (when logged in as a normal user). Test admin account by creating content in each folder. If it works - you will no longer need to modify "Everyone", as your permissions are defined under the other groups. I hope this all makes sense?

          Thats it in a nutshell really.
          I hope that this helps, and feel free to get back to me if you are still unsure?

          • 2. Re: UPK11 - multi-user environment - manage author permissions - help
            Thanks, Greig!
            I love your thorough instructions! They are very, very helpful.

            Here's a follow up question.

            Out of the box, the everyone group has "modify" permissions to all folders.

            The documentation says that when a person is in more than one group with conflicting permissions, the least restrictive permissions are granted.

            I created an HR group and gave that group read only permissions to certain folders.
            When I went into the library as one of those people and opened a topic, I was able to modify and check it out.
            This seems to me that the everyone group is over-writing the more restrictive HR group.

            I even tried to put permissions on an individual - and couldn't seem to make that work.

            Maybe I'm not interpreting what I'm seeing - I'll test again.


            BTW - if this is true - then my admins are part of the everyone group - if I make that group read only - I'm worried that I would hobble my admins!
            • 3. Re: UPK11 - multi-user environment - manage author permissions - help
              Hi Paul,

              My pleasure - it is nice to be able to get a definitive answer from someone when looking for help...

              With regards to your "out of the box" question:
              If you find that the Everyone group does in fact conflict with any other permissions that you have applied, remove the typical user(s) from that group, and login as them and test again.
              Unfortunately the permissions setup is more of a process of elimination based on what you (or the client) wish to have implemented based on securities and access.

              With regards to your admins being part of the Everyone group - to avoid all of your admins becoming "read-only" by assigning them to the Everyone group, do the following:
              Add one of the admins to a custom group that has FULL modify access to Root and sub-ordinate folders. Make sure that this specific admin is also not part of the Everyone group - then go ahead with your testing and see what happens. If you do manage to make all of your admins "read-only", you will be able to revive those users from the single admin account that you separated.

              One thing you must also remember - your Admin accounts will always have access to the "Administrator" menu in UPK - this then gives them access to Groups and Users. So even if all admins are "read-only", you can still modify the permissions of the groups and users for anyone; and return the original permissions as required! Does that make sense?

              Good luck - let me know how it goes!