Rights are granted in two places and the two never mix: a role in the company says what somebody may do to the company, a role in a project says what they may do to the work.
Roles in the company
| Role | What it gives |
|---|---|
| User | membership, and nothing beyond it |
| Trusted user | nothing on its own. It is the right to ask for administrator rights |
| Tenant admin | administering the company: users, configuration, security |
A trusted user is not half an administrator. They hold exactly what a user holds; the difference is that they may file a request for an administrator to decide. Only somebody who holds the administrator role permanently can grant it.
Roles in a project
| Role | What it gives |
|---|---|
| Viewer | sees the project and its issues |
| Contributor | creates and changes issues |
| Administrator | configures the project and hands out roles in it |
Project roles are given to a user or to a group. A role held through a group is the same role: the product does not distinguish where it came from.
The reporting tree grants nothing. A manager does not get access to the projects of the users who report to them by being their manager.
Borrowed rights
Administrator rights in Quevell are borrowed, not held. A company keeps few permanent administrators, and they do not spend their working day inside those rights; everybody else who occasionally needs to administer something asks for a window.
Which is how "why does this user still have full access" stops being a question anybody has to ask. The access ends on its own.
The request
A trusted user files it, under Administration. The entry is in their menu although they hold none of it: what it opens is not a refusal but the asking, and after the asking the same place says what came of it. The request carries three things:
- a start and an end for the window;
- a reason, between one and two thousand characters.
Checked as it is filed: the window has to end after it starts, and it must not already be over. A user has one open request at a time: while an earlier one is waiting or in force, there is no second. A request that is still waiting can be taken back by the user who made it, which frees them to ask again; taking it back is not a refusal but the absence of a decision, and the queue shows it as that.
The decision
A permanent administrator decides, and never the user who asked. That is the control: an approval always passes through a second pair of hands.
A refusal must carry a reason, exactly as the request does. A silent no teaches the user who asked nothing.
A decided request is not decided again: an approved one cannot be declined afterwards, and a declined one cannot be approved.
The window, and how it ends
The window ends itself. Whether it is in force is a question about now, asked at the moment somebody tries to do something, rather than by a scheduled job that can fall behind. At the end of the window the rights stop, and nobody has to press anything.
It can also be cut short: a permanent administrator revokes a window in force and it stops immediately. Rights that cannot be taken back before a date are not really borrowed.
The user is told about the decision, and about a revocation, by letter.
What a borrowed administrator cannot do
Two actions are closed to somebody holding rights through a window, and they are exactly the two by which an hour becomes permanent:
- seeing or deciding the queue of requests, which would otherwise let somebody approve their own extension;
- granting or removing administrators, which would otherwise turn a window into a permanent role in one click.
Both stay with the permanent administrators.
What is recorded
The request, the decision with its reason, and any revocation all land in the audit trail as entries with an author and a time. The trail shows not only what somebody did while holding administrator rights, but who gave them and on what grounds.