Reporting lines prototype

Table of Contents

Item Where
Prototype the prototype
Gemini review none
Group Membership prototypes
Journey Draw the reporting line

1. Summary

The reporting line is one field on the account: reports_to_account_id, a nullable soft self-reference. The shape only appears when somebody holds it in their head, and the journey is the screen that draws it and lets an administrator correct it.

The prototype reads the ACME demo dataset — 58 accounts, their job titles and their managers — lays it out three ways, and states every gap the journey records.

It is throwaway. It is not production code, it reads no service, and every value on it is mock data.

Open the prototype.

2. Detail

2.1. The verdict

Accepted on 2026-10-09: variant A, an indented tree with the selected person beside it. The rejected shapes stay in the prototype, switchable from the bar at the foot of the page.

2.2. The three variants

Variant Shape What it settles What it gives up
A · Tree An indented tree with expand and collapse, and the selected person in a panel beside it Depth and branches are plain, the whole tenant stays on one screen, and the controls have a fixed place It is not an organisation chart to the eye
B · Chart Boxes joined by connector lines It reads as an org chart, which is what an administrator often means by "the shape" It stops working at a few hundred people and on a narrow window
C · Table One row per person, indented by depth, with a manager column It is the easiest to search and to read a manager from The shape has to be inferred from the indentation

2.3. The declared gaps the screen states

  1. There is no tree read. The server answers one flat page of accounts, so the page nests the flat list in the browser. A large tenant cannot page a branch, and the whole roster must arrive first.
  2. The server accepts a loop. Nothing refuses A reports to B when B already reports to A. The manager picker leaves out every person who reports to the selected one, directly or through others, and the panel says that the screen is doing the check the server does not.
  3. There is no reporting-line-only write. One field means the whole update_account_request, so a concurrent change to another field is overwritten by the copy the page read.
  4. No office can be named. The card shows the party a person works in, and the association read carries party_id alone. Office values are marked in amber on the page.
  5. The line has no history here. The account is versioned and the screen states none of it.
  6. There is no approval. The journey makes a change a proposal that a hierarchical superior or a tenant administrator answers, and nothing holds one: no request, no queue, no notification and no decision. The A proposal case draws who decides and states that the line does not move.

2.4. The cases the bar switches

  • Clean tree is the ordinary case.
  • No lines is the empty state: nobody reports to anyone, every person is a root, and each is offered as a manager.
  • A proposal is the waiting case: one person asked to move, and the platform cannot hold the answer.

2.5. Why the tree is drawn from a flat read

The journey document says the tree is assembled by the client from a flat read, not fetched as a tree. This prototype does exactly that, so the cost is visible: the whole roster arrives before anything is drawn, and a tenant the size of a large bank would send every account to draw one branch. The tree read the journey proposes is the fix, and the prototype argues for it rather than hiding the problem.

3. See also

Emacs 29.3 (Org mode 9.6.15)