Responsibility Unlock - Restricting Access by Status

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:

Responsibility principles

1. The user can edit only those objects that has the same responsibility as the user has
2. A user can unlock an object that does not have the correct responsibility if the user's responsibility profile(s) contain the right "keys" - the same keys as the object has. If the user has the keys, he can change the object's responsibility to his own, thus "unlocking" the object
3. Objects that do not have the same responsibility or key set as the user, are permanently locked for editing by that user
4. A user can change the key set on any object only to those keys he has access to himself

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.

Sub-projects

01 -Team A
02 -Team B

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.

Occurrence States

01-Work Started
02-Ready for acceptance
03-Not accepted
04-Accepted
05-Closed

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:

PAMEM

Project A members- responsibility PAMEM - with access to:

• Project : 01 -Team A
• Occurrence State: 01-Work Started
• Occurrence State: 02-Ready for acceptance

PAMEM has access to editing occurrences (level 2), read accesses to other objects

PBMEM

Project B members - responsibility PBMEM - with access to:

• Project : 02 -Team B
• Occurrence State: 01-Work Started
• Occurrence State: 02-Ready for acceptance

PBMEM has access to editing occurrences (level 2), read accesses to other objects

ARC

Responsible archictect - responsibility ARC - with access to:

• Occurrence State: 01-Work Started
• Occurrence State: 02-Ready for acceptance
• Occurrence State: 03-Not accepted

ARC has access to editing both items and occurrences (level 1), read accesses to other objects

OWN

Building owner - with access to:

• Project 01 and 02
• Occurrence State 01, 02, 03 and 04

• Here, we call that responsibility OWN.

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".
      

      

      
      Figure 1 - creating the status types that will define responsibility keys
   4. Click "save", the screen should look like Figure 2.
      

      

      
      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

Troubleshooting: Status not showing

Please be aware - if you have created a status set that is connected to responsibility, eg. a status set consisting of statuses 01, 02, 03. These are assigned to different responsibilities- eg. ARC has 01, 02, and OWN has 01, 02, 03. If the admin creates a new status - 04 - no-one, including the admin, will be able to assign that status to an object until the status is connected to a responsibility set. So, if this is to be a status the OWN has permission to set, assign OWN = 01, 02, 03, 04 and save - then also the adm can set an object in status 04.