Items - User Rights
In dRofus, all items, occurrences, and products can be assigned a responsibility groups such as ARC, EL, IT, INT, and more. This categorization enables different user types to be assigned specific permissions and access rights. For instance, an architect with the ARC permission can view, modify, and delete all items and their occurrences, while an Equipment Planner with the EPLAN permission can view all items, update select occurrences and products marked as EPLAN, and any occurrences created by this user will be marked as EPLAN.
The responsibilities available within a project are determined by the Administrator, who also assigns the responsibility groups to each individual. To change the responsibility group of an item-related object, the user must have the appropriate permissions to modify both the current responsibility group and the desired one.
When a user has the necessary access rights to modify an item, it is displayed in a dark color. Conversely, if access is restricted, the item appears grayed out. For example, in the given scenario, the user has access to modify EPLAN occurrences but not ARC or DOOR occurrences.
These user rights are not only applicable when working in dRofus, but also when using any of the Add-ins, Admin operations (import/export), Reports and even direct SQL access operations.
Please look in the administration guide for how to set the different access rights.
Read Only Items
Half Tone Items
Read Only Items are Items that cannot be edited. When a responsibility group is set to 'Read Only' by a Project Administrator, the user will not be able to edit Item Data, or edit the Item Properties.
Note: The user is able to select a read only Item and Copy them to a Room.
The example above shows several Items that are part of the 'ARC' responsibility group that has been set to Read Only by the Project Administrator. The Items that are set to read only are in a half tone.
Items in Room
Items in an Items in Room List may also appear half tone if the user has read only permissions to the specific responsibility group. Items will also show as half tone when an Item List is driven by a Template.
Items in Room driven by a Template show this condition via the Status column.
For more information on permissions, click here.
Unlocking a locked item or occurrence by status
Items, occurrences and products can be restricted by responsibilities. You will see that an object has a responsibility other than yours by seeing that the property screen is grey and there is a lock in the top right corner.
dRofus can be set up so that you can "unlock" an object even if you do not have the same responsibility as the responsibility on the item. If that is the case, you will see a lock with a key in the top right. To unlock, the object has to have statuses that you have access to.
The principles are as follows:
Responsibility principles
You can edit any item, occurrence or product that has your responsibility on it (as long as the responsibility gives edit rights)
If an object does not have your responsibility, but it has the statuses that you have access to, you can change the responsibility to (one of) yours and save it. You then have update rights. In other words, it is locked, but you have the keys (the right statuses) and so you can unlock it (change responsibility, save).
When the object does not have any of your responsibilities, and you do not have the keys (right statuses), you cannot change it
When you have permission to change an object, you are still limited to change only the statuses that are associated with your responsibilities.
You can have more than one responsibility, and thus several status sets. The statuses you have access to are comprised of the total of you responsibilities.
An example:
Ariel, an architect, has been given the permissions ARC that is set up to allow her to edit both items and occurrences with ARC on them. ARC has been tied to Occurrence states = 01, 02 and 03 (see figure below)
Ariel opens an occurrence property panel for an object which is greyed out (see below). However, the state is set so that the occurrence is unlock-able (1). This is because the occurrence has 01- Work started (2). This occurrence also has another status - Projects 01 - Team A (3) that is not set up to be a key. The responsibility on the occurrence is Doors (4).
Ariel wants to work with this occurrence, so she changes the responsibility to ARC and saves. The locks disappear, and she can edit the occurrence as needed. However, if she tries to change Occurrence State, she only has the ones with "her" statuses available, i.e. Occurrence State 01, 02 and 03, and Project 01.
If a user that does not have the right responsibility, and does not have the right statuses, open this occurrence - for example Donald, who has responsibility DOORS and has access to 03 - Not Accepted but not to 01 - Work Started, the icon at the top right will show a lock without the key (1). Donald does not have the necessary statuses to unlock. He will not be able to edit this occurrence. See below.