Thanks Richard, really useful info. I'm fairly comfortable with setting up the appropriate roles and groups across multiple projects but did wonder how others handled the risk of cross-linking between projects that were not subscribed to the same public instances. I guess the answer is education and training as we will have quite a few publishers with multi-site permissions. Quick question, related I think, do you know if it's possible to deny users permissions to the command buttons (i.e 'New page', 'Activate changes' etc) ? Thanks Jon
>>> On 07/08/12 at 11:26, "Unger, Richard" <[email protected]> wrote: Hello Jon, I think many users of magnolia EE will face this issue * we certainly did. We handled this issue as follows: - We set up 3+ roles for each site: an admin role, an editor role, and a base role o The base role simply gives read-only access to the site-root and below, as well as a corresponding folder in DMS, and any category or data module content needed by the site o The editor role has write access to the site and the dms folder o The admin role has write access to the site, dms folder and data module content o Sometimes, for the larger sites, we have multiple editor roles with write access to different parts of the site - For each role we create a corresponding group o That lets us delegate the user management to *master-admin* users o The master-admin has read-access to roles and groups, and write-access to users. The roles menu is hidden from master-admins (by removing access to the *roles* menu item in the config workspace) o The master-admin therefore sees the groups and users, and can assign groups to users to handle the user management o Creating new roles is done only by us (superusers) - In DMS, we create a root folder for each site o The idea is that assets for a site are stored within the folder for that site o We also have a *shared* folder, that all editors have read-access to o We store common logos and other generally useful assets in the shared folder o The contents of the shared folder are managed by the *master-admins*, normal editors can only link to content stored there, not modify it If editors have more than one site, they see the trees for both sites. That can be a little confusing for the editors, but in our setup this is not a common occurrence, and the affected editors are generally more *power-users*, and therefore can be trained to deal with it. It could be an option to create multiple users for your editors who have to edit more than one site. In that case they could log in with one user when editing site A, and another user when editing site B. In this way they would only get to see one tree. On the other hand they would have to log out and back in to edit the other site. Whether this is more or less confusing than having 2 trees is open to discussion, I think. For us that was not an option in any case, as our editors log in via a SSO system, and could not easily switch users. *Cross-Linking* content from one site in another is supported by magnolia, and not actually a technical problem, unless the content is not subscribed on the same public instances. It can be an organizational problem if content from site A is used in site B, and a site A editor who is unaware of this deletes the content. Regards from Vienna, Richard Von: [email protected] [mailto:[email protected]] Im Auftrag von Jon RINGWOOD PSE 55500 Gesendet: Dienstag, 07. August 2012 12:02 An: [email protected] Betreff: [magnolia-user] Security - User Management Morning all, Just looking for a little advice on setting up users, groups, and roles within Magnolia EE. Do many people have multiple sites based in a single author that publish to multiple public servers? If so, how do you manage users that require access to those sites? It looks like it could be fairly confusing for them i f they log in and see several top level sites. Also do you ever experience problems with users mistakenly linking to documents and images from the wrong site? It looks like it could be easily done. Any advice most welcome. Thanks Jon ---------------------------------------------------------------- For list details, see http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to: <[email protected]> ---------------------------------------------------------------- ---------------------------------------------------------------- For list details, see http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to: <[email protected]> ---------------------------------------------------------------- ---------------------------------------------------------------- For list details, see http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
