<\/p>\n\n\n\n
The easiest approach to achieve this goal would be to set up two separate Mayan instances<\/strong>. This could be achieved with two separate virtual Mayan environments on one machine (which could then at least share a single database server running two separate databases). Or separating things further, we could even set up two completely different (virtual, Docker containers or even physical) machines which each contain the whole suite of services (PostgreSQL server, Redis, Venv and all the other stuff) on a standalone basis.<\/p>\n\n\n\n The main disadvantage of such an approach would be duplication. This is particularly inconvenient, when it comes to keeping all separate systems updated. Mayan releases an upgrade about each fortnight on average, and the process<\/a> is quite cumbersome. If you run a separate system for each org unit, this means having to go through the same tedious upgrade procedure each and every time. And the same might go for the operating systems of each virtual or physical machine.<\/p>\n\n\n\n Mayan prides itself for its highly granular and customizable access control. Not only does it allow an unlimited number of users<\/strong>, but it can also define an unlimited amount of groups<\/strong> which users can be added to and roles<\/strong> which determine the privileges<\/strong> granted to each group. User groups can than be awarded one or more roles through which member users obtain these privileges indirectly.<\/p>\n\n\n\n On top of that, each resource – be it a single document, a document type or even a cabinet comes with individual access control lists which can fine-tune the access privileges at the object level.<\/p>\n\n\n\n With all these instruments, it should be possible to keep separate org units on the same Mayan installation from messing around with each other’s documents.<\/p>\n\n\n\n The downside is that controlling access privileges with all these settings to toggle is not trivial at all. Worse still, the documentation<\/a> is limited to rudimentary descriptions. Even the book<\/a> only offers advice of the “in order to add a user to a group click the ‘Add user to group’ button” style. It elaborates in great detail on things that you would have known anyway but offers few instructions on conceptual matters. No worked examples worth mentioning which would have helped with our problem.<\/p>\n\n\n\n There were a couple of hints in the Mayan user foru<\/a>m, which helped a little and a worked example on users, roles and ACLS<\/a> from a blog unrelated to the Mayan EDMS developers. After a lot of trial and error, here’s how to set up a single Mayan instance to deal with completely different org units…<\/p>\n\n\n\n\n\n\n\n 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.<\/p>\n\n\n\n We will add user Using In line with the groups we created, we create the roles. We start with creating As the next step, we associate the group Now comes the important part: We set the permissions for After you are done, with 2. Sharing Mayan EDMS over multiple organizations<\/h2>\n\n\n\n
3. The How To<\/h2>\n\n\n\n
3.1 Add standard users<\/h3>\n\n\n\n
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).<\/p>\n\n\n\nwaldorf<\/code> who is a member of BBG and statler<\/code> who is a member of HFT.<\/p>\n\n\n\n3.2 Define Groups<\/h3>\n\n\n\n
Setup \/ Groups<\/code> as the admin, we create a group g_BBG<\/code> and g_HFT<\/code>. We then add waldorf<\/code> to g_BBG<\/code> and statler<\/code> to g_HFT<\/code>.<\/p>\n\n\n\n3.3 Define Roles<\/h3>\n\n\n\n
r_blank_bbg<\/code>. This is the role of the standard user from the group g_bbg<\/code> inside the BBG organization.<\/p>\n\n\n\ng_BBG<\/code> with our role r_blank_bbg<\/code>.<\/p>\n\n\n\nr_blank_bbg<\/code>. Though it may counterintuitive, we do not grant any permission at all to this group<\/strong>. The reason is that role permissions have always a system-wide effect. If we add a permission View Documents<\/code> to the role, this privilege is valid for any<\/strong> document on the system – exactly the thing we want to avoid. Users in group g_bbg<\/code> should only be able to view documents of the BBG organization and not of HFT – they should not be able to view any document.<\/p>\n\n\n\nr_blank_bbg<\/code>, create another role r_blank_hft<\/code> and repeat the same steps again, this time associating group g_hft<\/code> and granting no permission at all to this role.<\/p>\n\n\n\n
If you want to prevent end users<\/strong> from accessing certain documents or cabinets while giving access to certain other documents, you cannot do this by role permissions. The thing you have to go for is ACL<\/strong>s (access control lists).