Users’ action rights and user profile management
- For each user you can define ‘Action rights’: that is everything this user can or cannot operate on all of the various objects (SUT, Requirements, Specifications …)
- Action Rights are defined using ‘User profiles’
- Each user is associated to one ‘User profile’
By default, starting with version 3.1 , XStudio includes 4 basic User profiles:
- Viewers – can only see SUT, Requirements, Specification, Tests and Campaign/Sessions
- Doers – can do most actions except creating costumed fields, signing record, creating folders.
- Managers – can do all actions except creating companies
- Administrator – can do all action
And 3 specific ‘Doers’ – they have restricted actions rights as compared to Doers
- Business analysts – have less actions right on Test and Campaign/session
- Testers – have less actions rights on SUT, Requirements and specifications
- Developers – have restricted right on tests as compared to testers
At any time, you can clone and modify these ‘user profiles’ to match your specific needs. For example, some customers differentiate test operators from testers.
Note: At the start, try using only the 4 basic user profiles.
You can specialise taking 2 approaches:
- Restricting rights from the ‘Doers’ or ‘Managers’ user profiles. This is the easiest way
- Allowing rights from the ‘Viewers’ user profile. This is the most secure but it takes an iterative approach to get the right specialisation
Note: XQual recommends that you keep the number of user profiles to the minimum.
- Each user is also a member of at least one team.
- A team groups multiple members.
- For each team you define which folders is accessible.
- You can create teams per project, per function, per role.
- If a user is a member of multiple teams, the access rights are cumulative
- That is : the user can access all of the folders that are defined in the access list of each team
If none of the teams a user is a member of has access rights to a specific folder, this user will not even be able to see it.
Note: XQual recommends not being too restrictive on access rights at the start.
The following approach can be used to define your teams:
- Define what is common to all users (e.g. common requirements and specifications)
- Define what is restricted to some groups of users (e.g. Agents are only interesting for managers and administrators in medium size organisations)
- Define your organisation (e.g. per domain, per project….)
Create a team for each:
- One team for common objects
- One team for restricted objects
- One team per domain and/or project
- One team that ‘can see it all’
Then for each user associate him/her as a member of the teams
- Viewers are usually associated to Projects or Domains
- Doers are usually associated to Common objects and the projects they participate in
- Managers are usually associated to Common objects, Restricted objects and the domains
- Administrators are associated to “can see it all” team
Note: you can also work from a team to define all of its associated members. This is faster and easier if you are clear about who needs access to which projects and domains.
If you try to access an object for which you don’t have access rights (i.e. you are not a member of any team that has access to it), then you will receive an error message such as the following.
In such case, you need to ask your manager or administrator that you are a member of a team that has access to this object.