Principles

This feature is made for large project organisations that have a lot of different roles in their projects, and want to restrict the user's possibilities to edit particular items, occurrences/ components or products (here called objects).

It is built upon a set of principles:

The keys used are statuses that are connected to responsibilities in the user setup.

Example

A large project consists of several sub-project teams, two of which are called "Team A" and "Team B". The teams are both on the contractor side, and the building owner does not want them to be able to update each other's objects.

The building owner has also set up a work process for the occurrences that are currently being designed and put into place in the sub-projects. The work process consists of the states 01-Work started, 02-Ready for acceptance, 03- Not accepted and 04-Accepted. The project teams should be able to work with objects in state 01 and set the object to 02, the responsible architect has access to update objects in state 03, the building owner representatives can work with all states and are the only ones that should be allowed to set the objects to 04-Accepted.

In team A, there is an architect, Ariel A, and a designer, Desmond A. In team B there is an architect, Allan B and a designer Donald B. Desmond also works for project B sometimes.

The building owner has a representative Owen that works with quality assurance and acceptance, and thus is the one that goes through many of the deliveries and does the acceptance tests.

In the project, it has been decided that they will set up the following responsibilities:

Setting up permissions

1. Defining the statuses:

   1. You have to be a database admin

   2. Choose Settings - Project and database administration, then "Settings" -> Project -> Status

   3. Choose Add - then write the name of the status you want to use, for example "Occurrence State". Choose what the statuses should be valid for, in this scenario we have set Occurrence State to be "For occurrences" (see Figure 1) and Project "For rooms" and "For occurrences".
      
      

      Open

      

      Figure 1 - Creating statuses

      
      Figure 1 - creating the status types that will define responsibility keys

   4. Click "save", the screen should look like Figure 2.
      
      

      Open

      

      Figure 2 - both status sets in place

      
      Figure 2 - connecting status to object types for this project

2. Define the content of the statuses:

   1. You have to be an admin

   2. Choose Items (the items module)

   3. In the navigation panel on the left, you will now see "Occurrence States" and "Projects"

   4. Choose one, add the correct statuses. See Figure 3 for how the Occurrence States should look when you are finished.
      
      

      Figure 3 - finished setting up the Occurrence State topics

3. Assigning Responsibility groups to the statuses:

   1. Choose Settings - Project and database administration, then Settings -> Items -> Responsibility groups

   2. Choose Add

   3. Add the different responsibilities as described above. Here, we have added a "Doors Archictect" in addition to the three responsibilities described above (this is a doors database). Se Figure 4.
      
      

      
      Figure 4 - connecting responsibility and status

Giving the users their responsibilities

Now, we are ready to add the users Ariel, Desmond, Allan, Donald and Owen to the responsibility groups they need. Ariel A will need PAMEM and ARC. Desmond will need PAMEM and PBMEM. Allan will need PBMEM and ARC, Donald will need PBMEM. Owen will need OWN.

Here is how to do this in dRofus:
1. Create the user in the database. Consider if the users need to add or edit items (access level 1). Using standard Item right 3 - Read is recommended, this gives you control if you don't want the user to be able to write/ change any item or occurrence except special ones (see Figure 5).
2. Set up the access for the user. Here, I have shown how to set it up for Ariel - she has full access on ARC items and limited on PAMEM, meaning that if there are items in the database tagged with the ARC responsibility she can change those, and that she can create new items which have the ARC responsibility. Figure 6 shows her setup.
3. A member of Project A will typically have limited on PAMEM if they only are to create/edit occurrences, full on PAMEM if they also should be allowed to create new items with the PAMEM responsibility, and Read as default.

Figure 5 - this user can change the rooms, but only change items+occurrences with ARC, and occurrences with PAMEM.

Figure 6 - this user has two sets of permissions, all rights on ARC but limited on PAMEM.

Once the users are all set up , they can start using the database.

To see how this looks for the user, see Unlocking a locked item or occurrence by status.

A special case - giving users right to create occurrences but with no update rights to the item

One thing you may want in the project, is to allow users to create new occurrences in room for an item, but not allow them to update that item. To do that, you need to create a responsibility (for example, OCCnotITEM) that you tag all those items with that should be used as templates for the occurrences in question. You then give the users who should make the occurrences access to this responsibility, at level 2 (limited) in the user setup. The users will then be able to create the occurrence, and if you have given them other responsibilities with status rights, will be able to tag the occurrence with their own statuses.

Just remember that when a user creates such an occurrence, if she does not change the responsibility to another of her own, everyone else with the OCCnotITEM responsibility will also be able to change the occurrence. If you do not want that, there has to be a routine for the user to change the responsibility on the occurrence once it has been created.

Make sure your statuses are included on a Responsibility