In Quevell, access narrows to a single issue without touching anybody else's work, so HR, payroll and incident work does not need to hide in a separate secret project.
A security level
A security level is a named list of the people it admits. It is created in a project and belongs to that project.
An issue is either under a level or under none. An issue with no level is visible to everybody who sees the project, exactly as usual.
Narrowing only
There is one rule above the rest: a security level narrows the project's permissions and never widens them.
A user who cannot see the project cannot see an issue in it under any level, even a level that names them personally. A level decides which of the users who already have access to the issue through the project will see it. A level cannot widen access beyond the project.
That gives the property the whole design exists for: a mistake in a level cannot show an issue to somebody the project would not have shown it to. A mistake can only make an issue 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 who belongs to the group, and nobody else |
| Project role | everybody who holds that role in the issue's project |
Groups are not here for convenience alone. A level that lists users by name goes out of date on the day the membership changes; a level that names a group stays correct, because the only thing that changes is the group's membership.
A role held through a group counts: if a group holds the contributor role in the project and the level admits contributors, the members of the group are admitted.
Security administrators
Whoever holds the right to manage issue security in a project always sees that project's protected issues, whatever the list says.
An empty list of members means access for administrators only, rather than access for nobody. If the last entry is removed from a level, the issue stays visible to the users who can correct the setting, and it is not locked away for good.
A default level
A project can mark one of its levels as the default level: every new issue in that project is then created with that level. This is for projects where everything is protected rather than the occasional issue, and where trusting a user to remember 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 can show an issue applies it: project search, global search, lists, cards on boards. There is no separate path where the rule was forgotten, and that is by construction: otherwise one compatibility endpoint would quietly become a hole.
In practice a protected issue is absent from the search results of somebody the level does not admit; it never shows up with its contents hidden. It is simply not there.
The query language has no field for the security level: the level field is the hierarchy level of the issue type, not the security level.
How many issues a level holds
Every level shows how many issues are under it right now. A level that protects nothing shows a zero, and that is the one way to notice a level has fallen out of use rather than guessing at it.
What is recorded
Creating a level, changing its list, and putting an issue under a level all land in the audit trail with an author and a time. Who changed an issue's level, and when, is visible in the trail.