Document toolboxDocument toolbox

Responsibility-Based Access Control in dRofus

This feature is designed for large project organizations with diverse roles, aiming to restrict users' abilities to edit specific items, occurrences/components, or products (collectively referred to as "objects").

Core Principles

  1. User Editing Rights: Users can only edit objects that share their responsibility.

  2. Object Unlocking: Users can unlock objects with different responsibilities if their profile contains the appropriate "keys" (matching the object's keys).

  3. Responsibility Transfer: Upon unlocking, users can change the object's responsibility to their own.

  4. Permanent Locks: Objects without matching responsibility or key set remain locked for that user.

  5. Key Set Modification: Users can only change object key sets to those they have access to.

  6. Key-Status Connection: Keys are statuses linked to responsibilities in the user setup.

Example Scenario

Consider a large project with two sub-project teams: "Team A" and "Team B". Both are contractor teams, and the building owner wants to prevent them from updating each other's objects.

Sub-projects

  • 01 - Team A

  • 02 - Team B

Occurrence States

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

Team Members

  • Team A: Ariel A (Architect), Desmond A (Designer)

  • Team B: Allan B (Architect), Donald B (Designer)

  • Desmond also works for Team B occasionally

  • Owen: Building owner representative (Quality assurance and acceptance)

Responsibilities

Responsibility

Access Rights

Object Edit Level

Responsibility

Access Rights

Object Edit Level

PAMEM (Project A members)

Project 01, Occurrence State 01-02

Occurrences (Level 2)

PBMEM (Project B members)

Project 02, Occurrence States 01-02

Occurrences (Level 2)

ARC (Responsible architect)

Occurrence States 01-03

Items and Occurrences (Level 1)

OWN (Building owner)

Projects 01-02, Occurrence States 01-04

All objects

Setting Up Permissions

1. Defining Statuses (Database Admin)

  1. Navigate to Settings > Project and database administration > Settings > Project > Status

  2. Add new statuses (e.g., "Occurrence State", "Project")

  3. Set validity for each status (e.g., "Occurrence State" for occurrences, "Project" for rooms and occurrences)

Figure 1 - Creating statuses
Figure 1 - creating the status types that will define responsibility keys
Figure 2 - both status sets in place
Figure 2 - connecting status to object types for this project

2. Defining Status Content (Admin)

  1. Go to the Items module

  2. In the left navigation panel, select "Occurrence States" or "Projects"

  3. Add the correct statuses for each

3. Assigning Responsibility Groups to Statuses

  1. Go to Settings > Project and database administration > Settings > Items > Responsibility groups

  2. Add responsibilities as described above

4. Assigning User Responsibilities

  1. Create users in the database

  2. Set up access for each user:

    • Consider access levels (e.g., Level 1 for item editing)

    • Assign appropriate responsibilities (e.g., Ariel A: PAMEM and ARC)

Special Case: Occurrence Creation Without Item Update Rights

To allow users to create occurrences without updating the associated item:

  1. Create a new responsibility

  2. Tag relevant items with this responsibility

  3. Give users access to this responsibility at Level 2 (limited) in user setup

Note: Users should change the occurrence responsibility after creation to prevent unintended access by others with this new responsibility.

Troubleshooting: Status Not Showing

If a new status is created but not visible:

  1. Ensure the status is connected to a responsibility set

  2. Assign the status to the appropriate responsibility (e.g., OWN)

  3. Save changes

After these steps, administrators can set objects to the new status.