HR, payroll and incident work usually ends up in a separate secret project, because there is nowhere else to put it. In Quevell there is no need: access narrows to one issue without touching anybody else's work.
A security level
A security level is a named list of who is admitted. It is created in a project and belongs to that project.
An issue either stands behind a level or behind none. An issue with no level is visible to everybody who sees the project, exactly as usual.
It only narrows
One rule matters more than the rest: a security level narrows project permissions and never widens them.
Somebody who cannot see the project will not see an issue in it under any level, even a level that names them personally. A level answers "which of the users who could already see this issue will see it", and nothing else.
Which gives the property the whole design is for: a mistake in a level cannot show an issue to somebody the project would not have shown it to. The only direction you can get it wrong is less visible.
Whom a level admits
A level's list holds three kinds of entry:
| Kind | Who is admitted |
|---|---|
| User | one named user |
| Group | everybody in the group, and nobody else |
| Project role | everybody holding that role in the issue's project |
Groups are not here for convenience. A level that names users one at a time goes out of date the day somebody joins or leaves the team it was written for; a level named by a group stays true.
A role held through a group counts: if a group holds the contributor role in the project and the level admits contributors, the group's members are admitted.
The administrative override
Anybody holding the right to manage issue security in a project always sees that project's protected issues, whatever the list says.
That is deliberate, and here is what it buys: an empty list means "administrators only", not "nobody". A level whose last entry was deleted by accident leaves the issue visible to the users who can put it right, instead of sealing it forever.
A default level
A project can mark one of its levels as the default, and then every new issue in that project is born behind it. That is for projects where everything is protected rather than the odd issue, and where relying on somebody remembering to set a level by hand is not a plan.
Where the rule applies
The product has one visibility rule, written in one place, and every read path that could disclose an issue applies it: project search, global search, lists, cards on boards. There is no path where it was forgotten, by construction: otherwise one compatibility endpoint would quietly become a way to read what you should not.
In practice that means a protected issue does not appear in the results of somebody the level does not admit. It does not appear with its contents hidden. It is simply not there.
How many issues stand behind a level
Beside every level the product shows how many issues are behind it right now. A level guarding nothing reads as one, which is the only way to notice a level has fallen out of use rather than guessing.
What is recorded
Creating a level, changing its list, and putting an issue behind one all land in the audit trail with an author and a time. Who opened an issue up, and when, is read in the same place.