.png)
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
User Editing Rights: Users can only edit objects that share their responsibility.
Object Unlocking: Users can unlock objects with different responsibilities if their profile contains the appropriate "keys" (matching the object's keys).
Responsibility Transfer: Upon unlocking, users can change the object's responsibility to their own.
Permanent Locks: Objects without matching responsibility or key set remain locked for that user.
Key Set Modification: Users can only change object key sets to those they have access to.
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 |
|---|---|---|
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)
Navigate to Settings > Project and database administration > Settings > Project > Status
Add new statuses (e.g., "Occurrence State", "Project")
Set validity for each status (e.g., "Occurrence State" for occurrences, "Project" for rooms and occurrences)
Figure 1 - creating the status types that will define responsibility keys
Figure 2 - connecting status to object types for this project
2. Defining Status Content (Admin)
Go to the Items module
In the left navigation panel, select "Occurrence States" or "Projects"
Add the correct statuses for each
Figure 3 - finished setting up the Occurrence State topics
3. Assigning Responsibility Groups to Statuses
Go to Settings > Project and database administration > Settings > Items > Responsibility groups
Add responsibilities as described above
Figure 4 - connecting responsibility and status
4. Assigning User Responsibilities
Create users in the database
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)
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
Special Case: Occurrence Creation Without Item Update Rights
To allow users to create occurrences without updating the associated item:
Create a new responsibility
Tag relevant items with this responsibility
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:
Ensure the status is connected to a responsibility set
Assign the status to the appropriate responsibility (e.g., OWN)
Save changes
After these steps, administrators can set objects to the new status.