You can add, modify and delete roles. All access rights are managed via these roles. Each role is assigned an "access key" which determines the rights this role carries. User are being granted access rights for a specific project by the roles they carry in this project. User's roles may be different for different projects which allows for a detailed access right control.
Each role can be limited to have access to only certain list types such as mile stones, bugs, action items etc. If no list types are defined for a role, all list types may be accessed by default.
Track+ comes with quite a few roles preinstalled. You may safely delete those that you don't need.
Some access keys do not follow a general scheme and have a special meaning.
An access key of 999 designates a project administrator. A project administrator has special rights for a specific project only, namely the one he is assigned this role to. He may add other persons to the project and assign roles to them. He may also remove persons from projects. He can add, edit and delete subsystems, classes, and releases. He will see the appropriate pages in the web interface that other people will not see. A project administrator has complete access to all issues of a project.
An access key of 777 designates a person that will appear in the "manager'' list box of an artifact. At the same time, this person will have complete access (create, read, modify, and close) to all issues in this project.
An access key of 770 designates a person that will appear in the "manager'' list box of an artifact. However, read, modify, and close rights are only granted for the artifact where this person is the actual manager.
An access key of 666 designates a person that will appear in the "responsible'' list box of an artifact. At the same time, this person will have complete access (create, read, modify, and close) to all issues in this project.
An access key of 660 designates a person that will appear in the "responsible'' list box of an artifact. However, read, modify, and close rights are only granted for the artifact where this person is actually responsible for.
The access keys mentioned above may be extended with a leading "1'' or "2'', modifying the right to close an issue as described below.
In general, the access key schema consists of a four digit number where leading zeros are not shown (i.e. a regular positive integer number). Each digit has a meaning, if the number is not one of the special access key described above.
The first, most significant digit controls permission to close an artifact, i.e. to change the state of an artifact to a state with a stateflag marking this state as a "closed'' state. If this digit is "0'' or does not exist, complete permission to close an artifact is granted.
A "1'' means an editor may close this artifact if he is the creator, the current manager or the responsible of this artifact.
A "2'' means an editor may close this artifact if he is the creator or the current manager. All other numbers are treated as "0''.
The second digit from the left controls read access to an artifact. If this digit is a "0'' permission to read an artifact is not granted in this role, not even for the artifacts that this user has created. This may thus not be a very useful configuration. If this digit is a "1'' permission is granted to read all artifacts this user has created himself. If this digit is a "2'' permission is granted to read all artifacts in this project. All other numbers are treated as "0''.
The third digit from the left or second from the right controls permission to change an artifact. This includes permission to read an artifact. If this digit is a "0'' permission to modify an artifact is not granted in this role, not even for the artifacts that this user has created. If this digit is a "1'' permission is granted to modify all artifacts this user has created himself. If this digit is a "2'' permission is granted to modify all artifacts in this project. All other numbers are treated as "0''.
The least significant digit controls permission to create an artifact in this project. If this digit is a "0'' permission to create an artifact in this project is not granted. If this digit is set to "1'' permission to create an artifact is granted. All other numbers are treated as "0''.
Some roles have identical access rights. However, since it is possible to define for each role and each project type which lists are visible, this makes sense. The default setup limits access to the lists "work packages'', "action items'', and "milestones'' for the roles of Technical Sales and Procurement. All other roles have access to all lists. This setup can be changed by modifying entries in table TROLELISTTYPE.
|
Example Role |
Access Key |
Meaning |
|
Administrator |
999 |
Project administrator |
|
Developer |
221 |
A powerful developer. May create, read, modify and close everything |
|
Developer 2 |
1221 |
May create, read, and modify artifacts, but may only close his own artifacts and those that he is responsible for |
|
System Proving |
221 |
Same access rights as Developer |
|
PM |
220 |
Product management. May read, modify and close, but nut create new artifacts |
|
Extern |
111 |
External people, can only see and work with their own artifacts |
|
Extern 2 |
331 |
Can create artifacts, but can only read and modify his own artifacts and those of people that also carry this role |
|
Manager |
777 |
Manager appears in manager list, can create, read, modify and close everything |
|
Responsible |
660 |
Responsible appears in responsible list, can create, read, modify and close all artifacts she is responsible for. For upgraded installations from releases earlier 3.0.0: used to be "666'' |
|
Responsible 2 |
2660 |
Can not create artifacts under this role, can only read and modify his own artifacts and those where he is responsible for, may not close an artifact unless he is the creator (under a different role) or the manager. |
|
Technical Sales |
221 |
See "developer'' for rights. This role exists so that the visible lists can be different from those of a developer (e.g. Technical Sales people should not see the bug list) |
|
Technical Sales Manager |
Same as "manager''. This role exists so that the visible lists can be different from those of a regular manager (e.g. the technical manager may not be allowed to see the current bug list) |
|
|
Technical Sales Responsible |
666 |
Same as "responsible''. This role exists so that the visible lists can be different from those of a regular responsible (e.g. the technical responsible may not be allowed to see the current bug list) |
|
Procurement |
221 |
See "developer'' for rights. This role exists so that the visible lists can be different from those of a developer (e.g. procurement does not need to see the development lists such as problem reports or requirements) |
|
Procurement Manager |
777 |
Same as "manager''. This role exists so that the visible lists can be different from those of a regular manager (e.g. procurement does not need to see the development lists such as problem reports or requirements) |
|
Procurement Responsible |
666 |
Same as "responsible''. This role exists so that the visible lists can be different from those of a regular responsible (e.g. procurement does not need to see the development lists such as problem reports or requirements) |
Multiple Roles
It is quite common that a person is assigned multiple roles. For instance, the project administrator may also be a manager or responsible for some artifacts.
Access rights are handled such that the higher privileges always overwrite the lower privileges. For example, if a person may create issues, but may not read other peoples artifacts in the role "External'', if this person is made responsible for an artifact it will be able to read this artifact. It a person is designated as "external'' and may thus handle only it's own artifacts, if it is also assigned to a "Developer'', it will have at least all these more extensive rights of a general "Developer''.
There is no way to "subtract'' an access permission via a role; access right always add up.