Availability
An access level has two sides to it. On the one hand, it defines permissions a user of the system enjoys as he or she uses it, and, on the other hand, an access level comprises a set of permissions a user has in relation to a project(s) the user is (or is not) part of. Since the system as a whole is always wider than any project created inside it, there may be roles that are global to the system. Also, even when a user is not part of a project, he or she still may have certain permissions in relation to it (like viewing project members or issues submitted). Part of Birdview's great flexibility lies in that access levels users have can be changed widely.
It is important to distinguish between global and project-related parts of the system. For example, creating customers or generating overall reports clearly pertain to global functions of the system. On the other hand, creating a task within a project is apparently a project-related function.
Birdview comes with a number of access levels, of which some are built-in access levels, and some — predefined ones.
Access level priority
Some access levels take precedence over other access levels. E.g. if you are Project owner in a project, you will automatically have a full set of permissions, even if your global access level does not. The following diagram explains the hierarchy of access levels in Birdview.
On the practical side, the access level priority principle translates into the following rules of thumb:
- If a user is NOT a member of either a project, or a portfolio, his permissions are taken from his global access level.
- If he is a member of a portfolio, his portfolio-related permissions override his global ones.
- If he is a member of a project, his project-related permissions override his global ones.
- If he is a member of a project and a portfolio, his project-related permissions override his portfolio-related ones.