Rights are granted in two places and the two do not mix: a role in the company says what a user can do to the company itself, a role in a project says what they can do to the work.
Roles in the company
| Role | What it gives |
|---|---|
| User | membership in the company, and nothing beyond it |
| Trusted user | nothing on its own. It is the right to ask for administrator rights |
| Company administrator | membership of the "Super-admin" group: administering the company: users, configuration, security |
A trusted user is not half an administrator. They have exactly the rights any user has; the difference is that they can file a request for an administrator to decide. Only a standing administrator can add somebody to the "Super-admin" group, which is what makes them an administrator.
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 group is a list of users the company keeps under Administration; it exists so that access is granted once and only the membership changes afterwards. A role held through a group is the same role: the product does not distinguish a role granted directly from one that arrives through membership. Groups are not teams: a team is assembled by the users in it, and grants nothing.
The reporting tree does not affect rights: a manager does not automatically get access to the projects of the users who report to them.
Access decides what the inbox shows as well. Updates arrive only for the projects a user can open, and when access to a project is taken away, its updates leave the inbox with it.
Borrowed access
Administrator rights in Quevell are borrowed for a while, not held. A company keeps few standing administrators (the people who hold the role permanently), and they do not use those rights day to day; everybody else who occasionally needs administrator rights asks for the rights for a window.
That way "why does this user still have full access" never comes up: the access ends on its own.
The whole path, end to end:
- Who can ask. Only a trusted user. A plain user is given that role first, by a company administrator, under Administration.
- Who sees the request. The queue of requests is visible to the company's standing administrators, and to them alone. Borrowed rights do not open it.
- Who decides. Any standing administrator other than the one who asked. A rejection carries a reason.
- What happens at the end of the window. The rights stop working by themselves, with nobody acting. A standing administrator can revoke them earlier.
An hour of project administration
Rights over a single project are taken differently from rights over the company. A company administrator can take an hour of any project's administration on their own authority, with no request and no approval: a project left without an administrator would otherwise have nobody to bring it back. The hour starts when it is taken, taking it again restarts the clock, and it can be handed back early. Every time the rights are taken or handed back, it lands in the audit trail, with the reason if one was given.
The overview of company roles is in Getting started.
The request
A plain user cannot ask for the rights. The request is filed only by somebody a company administrator has already made a trusted user; that role opens nothing but the right to ask. The request is filed under Administration. The section is in their menu although they hold none of it: behind it is the request form rather than a closed door, and after filing, the same place says what came of it. The request carries three fields:
- the start of the window;
- its end;
- a reason, between one and two thousand characters.
On filing, the window must end later than it starts and must not already be over. A user has only one open request at a time: while an earlier one is waiting or in force, a new one cannot be filed. A request that is still waiting can be taken back by the user who filed it, which frees them to file another; a request taken back does not count as a rejection: no decision was made, and the queue shows it as exactly that.
The decision
The decision is made by a standing company administrator, and it cannot be the user who filed the request. That is the control: an approval always passes through a second pair of hands.
A rejection must give a reason, exactly as the request does. A silent rejection teaches the person who asked nothing.
A request that has been decided is not decided again: an approved request is never declined afterwards, and a declined one is never approved.
The window and its automatic end
The window expires and the rights are removed automatically. Whether the rights are in force is checked at the moment a user tries to do something, not by a scheduled job that can fall behind. At the end of the window the rights stop working, and nothing has to be pressed.
The rights can also be removed earlier: a standing 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 gets an email about the decision, about a revocation and about the expiry: granted or rejected and why, revoked before the end, or the window running out by itself.
What borrowed rights do not open
Two actions are closed to somebody holding the rights for a window, and they are exactly the two that could turn an hour into a permanent role:
- seeing and deciding the queue of requests, since otherwise anybody can approve their own extension;
- granting and removing administrators, since otherwise rights for a window turn into the role itself in one click.
Both actions stay with the standing administrators. Every other part of administration is open while the window runs: users, fields, workflows, notification rules, system settings. Workflows are named here because they are the commonest reason to ask for an hour: a borrowed administrator edits and publishes them just as a standing one does, and when the window ends the workflow screen becomes read-only for them again.
Signing in as another user
In the interface this is the Sign in as … button on a user's card. It opens the product the way that user sees it, and it exists for support: "my board does not open" is checked in a minute instead of over a thread of screenshots.
- Signing in as somebody requires the right "Sign in as a user". Company administrators always hold it; other users are granted it.
- You can sign in only as an active user of the company, and never as an administrator: that would hand over the company.
- The viewing ends by itself within an hour, and you can return to yourself in one click at any time.
- The user being signed in as gets an email about it.
- Every audit record made during it carries both names: the person looking and the person being looked at. There is no separate invisible mode.
What is recorded
The request, the decision with its reason, and any revocation land in the audit trail as separate records with an author and a time. The trail shows not only what a user did while holding administrator rights, but who granted them and on what grounds.