Username:
Password:
Please type the Two words with a space between them to prove you are a real human being.
A new Switch User facility has been implemented in Toolset and WorkBench whose purpose is to allow users to easily change between multiple user profiles without the need to supply passwords and without the need to log-out from one user profile and log-in again to another user profile.
A new Switch Identity attribute has been added to user profiles. If multiple user profiles have the same Switch Identity, then a user can use the new Switch User facility to change from the current user profile to any other user profile which has the same Switch Identity:
Switching to a new user profile is therefore an automated shortcut to logging-out from the current user profile and logging-in to the new user profile except that a password is NOT required.
Once you have switched to a new user, all actions that you perform within Cradle are logged as the new user to which you have switched, not the user that you switched from.
There are no limits to the number of times that you can switch user.
A user profile’s Switch Identity attribute can only be set if you have read-write access to the user profile. If you have no access to a user profile, you cannot see any part of it, including the Switch Identity. If you have read-only access to a user profile, the Switch Identity is disguised in the same manner as the user profile’s password.
Note that because this facility allows a user to switch to a user profile without supplying a password, including switching to a user profile with more privileges or in a different team to a user’s current user profile, the Switch User facility should be used with care.
Partly for this reason, you cannot set a Switch Identity for the MANAGER user profile.
In Toolset you enter the Switch Identity in the User Profiles screen:
In WorkBench you need to enter the Switch Identity in the User Setup screen:
Once this is done, in Toolset, you can choose the Switch to User… option from the File pulldown menu. The Switch Username Selection List is produced and you can choose the user you want to switch to.
In WorkBench you can use the Switch to User cascade menu which can be found under the File pulldown menu. This shows a list of users you can switch to:
In Web Access you use the Switch User selection list. This shows a list of users you can switch to:
Five new user privileges have been added to user profiles:
In the Toolset’s User Setup tool:
In the WorkBench User Setup tool:
The new DRAFT_ALL_RO and TEAM_ALL_RO privileges are powerful as they circumvent the effect of the team hierarchy as defined by the project. They should be granted with care.
By default, users have access to their own information and information owned by other members of the same team. The TEAM_UP_RO and TEAM_DOWN_RO privileges can be used to give users read-only access to information owned by the teams above and below theirs (respectively) in the team hierarchy. The TEAM_BYPASS privilege can be used to give users read-only access to information owned by teams that are siblings of their team in the team hierarchy, and the users who belong to these sibling teams.
So in this example project organisation structure with a simple team hierarchy, a user M without any privileges has access to information owned by his colleague N:
If user M has the privilege TEAM_BYPASS, then he/she will have read-only access to information owned by sibling teams and the members of such teams. In the example team hierarchy, this will give access to the items shown by the shading in the figure below:
If user M has the privilege TEAM_DOWN_RO, then he/she will have read-only access to information owned by sub-teams of his/her team, but not the members of such teams. In the example team hierarchy, this will give access to:
If user M has the privilege TEAM_UP_RO, then he/she will have read-only access to information owned by super-teams (parent teams) of his/her team, but not the members of such teams. In the example team hierarchy, this will give access to:
Therefore, all of these privileges preserve the concept that a hierarchical team structure partitions the data in the database so that information owned by one sub-tree of teams is not accessible by members of another sub-tree of teams. In the example, information owned by users of teams or sub-teams below TEAM A is not accessible by users who belong to TEAM B or any of its sub-teams.
Collectively, these privileges allow a project to partition access to information based on the user-defined hierarchy of teams in the project’s organisation structure.
The new DRAFT_ALL_RO and TEAM_ALL_RO bypass the partitioning effect of the team hierarchy.
If user M has DRAFT_ALL_RO then he/she has read-only access to information owned by all users, irrespective of which team they belong to. In the example team hierarchy, this will give access to:
If user M has TEAM_ALL_RO then he/she has read-only access to information owned by all teams, irrespective of where the team is in the team hierarchy. In the example, this will give access to:
Roles are a convenient method to assign a standard set of privileges for different types of user. When a new user account (called a user profile in Cradle) is being created, the contents of that new profile can be initialised to be a copy of a specified role.
In Cradle-5.7, it is possible to apply all of the role, or just the set of privileges defined for the role:
which has the benefit that the privileges in a role can be changed, and then the updated role can be used to set the privileges of existing user profiles without the other attributes in the user profile being changed.
Back to the newsletter archive.
