Site Overlay

Restrict document access for users in Mayan EDMS

4. Testing

Log in as user waldorf and try to upload a document for BBG group. When choosing the document type, you should only be able to see document type BBG – not HFT.

After having uploaded the document, check if you can see the document under Documents / Recently created and access its features.

Then log out and log in as user statler and see if you can proceed the same way loading up a document for HFT. Again when picking the document type, you should only see HFT, not BBG (or Default). Check if you can see your document under Documents / Recently created – and make sure, the BBG document you uploaded recently as waldorf does not show up among the recently created docs.

Pick the cabinets and make sure that only the HFT cabinet is visible, not BBG.

Add some search term unique to the BBG document to the search box and make sure, the search does not return the BBG document you checked in as waldorf. You should get an empty search. Repeat the test with a search term unique to the HFT document you just checked in. The search should return the document to you.

5. Open issues

We still have the following issues to deal with:

5.1 Tags and metadata org specific or not?

Should user be allowed to create new tags (pro: the one who uploads a new document knows best what tags to associate with the doc, con: redundant tag names – once a user adds tag ‘capital gains tax’, the next time it’s ‘capital tax’)

How handle metadata? We assume that metadata are always doc specific. So by forcing a particular set of doc types for a user group, we automatically force the metadata types. At least I would expect that – but we have to check.

5.2 Extension of a single org Mayan into a multi-org Mayan

Assume we have started with a single org Mayan which has thousands of docs checked in by the admin. How can we amend this instance of Mayan to the setup above? We want another organization to be able to also add its documents and separation of privileges along the lines we demonstrated in the previous sections.

The draft to do list is probably like that:

  1. Create a user for the current organization
  2. Create a group for the current organization
  3. Create a blank role for the current organization, associate role to the group just created
  4. Create doc types for the current organization and set ACLs associated with the doc type and the blank role
  5. Create cabinets and sub-cabinets for the current organization and set ACLs associated with the cabinet and the blank role
  6. Use some bulk editing to alter the document types of all documents previously checked in under the “global” document types. This should be the tricky part.

5.3 Extend direct SQL search to restrict results to a single organization

The very purpose of any document management system is its ability to quickly and reliably retrieve a particular set of documents from the thousands of documents which have been archived in the system.

Unfortunately, Mayan’s search function is not only badly implemented but also features an incredibly lousy documentation. The only way I found to save Mayan from becoming useless due to its search function is to bypass it by directly querying the PostgreSQL data base.

The SQL scripts currently allow to to retrieve the Mayan document IDs for a certain document given a search string to match and some metadata information. These scripts must be extended to restrict search results to a particular cabinet hierarchy or document type.