Administration » Users and Permissions » Example - Acme Inc.

Example - Acme Inc.

After some edits to permissions you need to logout of the manager and log back in, so after doing so, try logging out of the manager, logging back in as admin, then you should be able to edit the documents and set the group they belong to.

The user and permissions structure will be made clear using the following example.

You are building a web site for ACME Inc., makers of Instant Holes, Coyote Rockets, and Birdseed. In addition to having your site full of product information, you would like to include technical information and tutorials for the use of your products. And naturally, the marketing department would like a dominant presence. So you have created the following document structure:

Users (Who)

In our example, we have the following people that want to be involved with the website. So we have a different user defined for everyone:

User groups (Who)

User groups group users (clever huh?) who have to have access to the same documents. This could be users from the same functional area of the organization.

In our example, we create the following user groups:

As you can see, it’s possible for a user to be a member of multiple user groups.

Roles (What)

A role defines what a user can do within the document groups he has access to. Nota bene: within all the document groups he has access to. This means that if you want a user to have full rights in one document group but only reading rights in another, you have to create a different user for that.

The permissions that can be set in a role speak for themselves.

Within ACME Inc, Sylvester works for Pepe, and Pepe doesn't want to give editing control to Sylvester, but wants to use him for proofing. Everyone else needs to be able to edit their area of expertise. So there are 3 roles.

Document groups (Where)

So now there are users and there are roles. An important thing to think about is how documents are grouped. Document groups bundle similar documents together where they can easily be managed. In the ACME example, the following was decided upon.

Linking it together

The crucial part in making access permissions work is to associate user groups to document groups in a smart way. Here you determine the relationship between which user can edit which document. 

You can see that marketing can review (Sylvester) or edit (Pepe) any Info page, Tutorial, or Support page. But they cannot touch Tech pages (making the engineers very happy). The tech group has access to their small group of very focused technical pages, and they can also make fixes on the tutorials if necessary. But since that overlaps with marketing, there would need to be some communication. And the Support group can keep shipping information accurate, as well as have editing control over tech/tutorial info. This makes sense to you because support hears from the consumer and knows what kinds of questions need to be addressed, and therefore can write that info into the documentation.
 
Bugs, being the Admin, still has full access to everything.

Diagram

Putting it into a schematic, this is what the permissions structure for the ACME Inc. website would look:

Users and group diagram

Overlaps

Overlaps, as you can see from the example, are quite possible, and very useful. But one must use caution to be sure that the groups who have access to the same documents are aware of that and are willing to work together.