Restrict document access for users in Mayan EDMS

3. The How To

Suppose we have two organziations: The Baltimore Buyout Group (BBG) and the High Frequency Trading Corp. (HFT). Both HFT and BBG want to use the single Mayan instance we are running, and we have to guarantee that each org can only see or alter the content they uploaded themselves and not the other one’s content. In other words, each group should have the impression that it is the only user of the system. The only persons which should have unlimited access to any document on the server are the users that have been connected to the admin role.

3.1 Add standard users

As the admin, the first thing to do is to set up standard users in Mayan. Broadly speaking, these users should be able to upload new documents to the server, perform searches on the documents that belong to their org unit and do basic editing like adding or removing tags, filing into cabinets (but only those belonging to the own organziation), maybe deleting documents (but not from the trash).

We will add user waldorf who is a member of BBG and statler who is a member of HFT.

3.2 Define Groups

Using Setup / Groups as the admin, we create a group g_BBG and g_HFT. We then add waldorf to g_BBG and statler to g_HFT.

3.3 Define Roles

In line with the groups we created, we create the roles. We start with creating r_blank_bbg. This is the role of the standard user from the group g_bbg inside the BBG organization.

As the next step, we associate the group g_BBG with our role r_blank_bbg.

Now comes the important part: We set the permissions for r_blank_bbg. Though it may counterintuitive, we do not grant any permission at all to this group. The reason is that role permissions have always a system-wide effect. If we add a permission View Documents to the role, this privilege is valid for any document on the system – exactly the thing we want to avoid. Users in group g_bbg should only be able to view documents of the BBG organization and not of HFT – they should not be able to view any document.

After you are done, with r_blank_bbg, create another role r_blank_hft and repeat the same steps again, this time associating group g_hft and granting no permission at all to this role.

3.4 Add document types

Now we start actually separating privileges to access particular documents along organizational lines.

As admin, we create a document type (Setup / Document Types / Action / Create new document type) bbg_bank_statement, which users from BBG should be allowed to use to process any of their bank statements in the system.

Now comes the important part: For that document type, click on ACL, then click New ACL and select role r_blank_bbg. Then grant the following set of permissions to that role:

After adding the above permissions, you ACL should look somewhat like this:

You can now repeat the same steps for any other document that should be accessible for another group-role combination. For instance, you can create a document type hft_contract which holds all contract documents of the HFT organization.

Again click on ACL, select role r_blank_hft and then assign the same set of privileges as above to r_blank_hft for document type htf_contract.

Any new document type set up with the above types will inherit the role/group specific acces privileges.

3.5 Set up cabinets

As a second means to separate document access privileges and organize documents along organizational lines, we can set up cabinets. Again, these cabs should only be visible and accessible to the org unit for which the cab was created.

As the admin, click on Cabinets / Create Cabinet and create a main cabinet called BBG. This is the top-level cabinet under which every document associated to cabinets in the BBG org is filed.

Then click on ACLs, select r_blank_bbg and add the grant the following permissions:

Proceed the same way creating a top level cabinet HFT, select role r_blank_hft and grant the same set of permissions as above.

Admins (not the standard users) are authorized to add sub-cabinets to the root cabinets we just created. These sub cabinets will automatically inherit the role/permissions features of the root cabinet they are created under.

3.6 Tags and Metadata

As with document types and (sub-)cabinets, tags must be created by the admin. Standard users are allowed to use these attach or remove these tags to documents, but cannot create, edit or delete new tags on their own.

Once the admin has created a new tag, the tag’s ACL can then create a role/permissions combination in the same way we did earlier with document types and cabinets: