Availability
Overview
The 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, the 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 access levels that are global, or system-wide. 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 the access levels that the users have can be changed within a wide range.
It is important to distinguish between global, space, portfolio and project-related parts of the system. For example, creating customers or generating overall reports clearly pertain to global functions of Birdview. On the other hand, creating a task within a project is apparently a project-related function. Similarly, editing projects belonging to a portfolio is a function of the Portfolio Editor portfolio access level. Editing members of a space is and administrative function within the space.
Birdview comes with a number of access levels, of which some are built-in access levels, and some — predefined ones. Both can be edited and deleted, with two exceptions:
The built-in access levels of Administrator (ID#1) and Project owner (ID#2) cannot be deleted.
Access level priority
Access level tiers have a certain order of precedence with regard to a project. E.g. if you are a project owner in a project, you will automatically have a full set of permissions towards the project , even if your global access level does not. The following diagram explains the hierarchy of access levels in Birdview.
In other words, the access level tiers are in the following order of precedence, in relation to projects, from the most powers to the least:
- Project access level
- Portfolio access level
- Space access level
- Global access level
On the practical side, the access level precedence principle translates into the following rules of thumb (some rules may in part overlap with others):
- If a user is a member of a project, his project permissions overrides his portfolio, space and global ones.
- If a user is NOT a member of either a project or a portfolio, his space permissions override his global permissions with regard to projects in that space.
- If he is a member of a portfolio, his portfolio permissions override his global and space ones with regard to the portfolio projects of which he is not a member.
- If he is a member of a non-portfolio project, his project-related permissions override his space and global ones.
- If he is a member of a portfolio project and the portfolio, his project-related permissions override his portfolio-related ones.
- If he is not a member of a portfolio project, and he is a member of the space and the portfolio, his portfolio permissions override his space permissions with regard to the project.
Video opens at 0:12: access levels and predefined roles