What the tree is built from
The organization chart in Quevell is built from one fact in the profile: who reports to whom. Nothing separate has to be kept in step with reality.
The company marks one of its profile fields of the user kind as the manager field. Everybody with the field filled in appears under the user it names; everybody with it empty sits at the root of the tree. There is no separate structure that can fall out of date: changing that field on a user's page updates the tree on its own.
The manager field
- Only a field of the user kind can be the manager field, and only one per company. Choosing a new one takes the title from the old.
- It is chosen and cleared by whoever holds the right to edit the chart. That is a right of its own: one fact, one door.
- The root of the tree has an empty manager field: usually the owner of the company. Nobody reports to themselves, and such a value is rejected on entry.
- A manager who has left the company is no longer a manager: their direct reports move up to the root of the tree rather than hang under somebody who is gone.
Who sees it
The tree names every user in the company and draws the lines between them, which reveals far more than "my colleagues on this project". Viewing the chart is therefore a right of its own. Company administrators always have it; other users or groups are granted it.
Under a user's name the tree shows the values of profile fields flagged to appear on the chart: a job title, for instance. Only what is filled in is shown.
Cycles
If A reports to B and B reports to A, that is a cycle. A new one can no longer be created: a value that closes the reporting line, directly or through a chain (A reports to B, B to C, C to A), is rejected when it is saved. Users caught in a cycle from before that check are not drawn in the tree and are listed by name beside it: that way they stay visible and can be corrected.
The chart in search
The tree answers QQL queries through two functions:
assignee in (myReports()): the issues of my direct reports;assignee in (myVertical()): the issues of everybody below me, to any depth.
Both functions resolve for whoever runs the query: a filter saved by one manager shows another manager that manager's own reports. For these functions, users caught in a cycle report to nobody and have no reports.
That is deliberate, and it replaces "your report was assigned an issue" notifications: a manager looks at their reports' work when they choose to look, and nobody's inbox fills up on its own.
Teams are not the tree
Teams in Quevell live apart from the reporting tree: a team is assembled by the users in it, and it is not required to match the reporting line. The myTeammates() function answers by teams rather than by the tree: everybody from every team you belong to. Project rights do not follow from the tree either: they are granted by project roles, to a user or to a group.
Handover and access
When a user leaves, an administrator sees everything assigned to that user (assignments, roles, rules) and hands it to a successor in one action. The handover happens whole or not at all.
What moves to the successor: open assignments, open issues where the leaver is the reporter, project roles, automation rules, personal pages and saved filters. Roles move rather than being copied: no personal role in those projects is left behind. Access through a group is a separate matter and the handover does not touch it: somebody who belongs to a group that holds a role in a project keeps seeing the project through the group. Where the successor already held a role in a project, that role stands: a handover widens access and never lowers it.
Authorship never moves. Issues, comments and attachments stay signed by whoever made them, and the assignment on a finished issue stays as well: it is the record of who finished it.
The tree meanwhile does what is described above: a deactivated manager is no longer a manager, and their direct reports move up to the root. Their own manager field is not erased.
When a deactivated user is reactivated, the manager field is checked: if the manager it names is still in the company, the field is kept and the reporting line is restored. If that manager has been deactivated or deleted in the meantime, the field is emptied and the reactivation response says "no manager set: the previous one was deactivated". No confirmation is requested, and the clearing goes into the audit trail.