Administrator dashboard access

This is LNT-418, the second piece of the administrator dashboard. LNT-417 stored the numbers; this ticket decides who may open the dashboard, and how far each person can see. On the right is the whole answer in four lines: a system administrator sees every branch, a branch administrator sees their own branch and cannot change it, a Reports viewer sees the branches they belong to, and anyone else cannot open it.

Today the only way into the Admin area is the Administrator permission, and that permission also lets you manage every user and their access. In a library system those are usually different people. The system wants someone who can read how things are going without being able to change who has access. And a branch administrator must never see another branch's staff or patrons, by any route. So the dashboard needs its own way in, and every screen needs to know how far each person may see.

Three things changed. First, a new permission called Reports viewer, described as "see how the system or branch is doing". A library system gives it and takes it away on the same Users screen as the other two, and every change is recorded in the user's history. Second, an Insights tab in the Admin area, next to Circulation, the same idea as the branch desk's Insights. Either the Administrator permission or Reports viewer opens it. Third, nothing else opens: a Reports viewer cannot manage users, and Circulation, Users and Settings still say No permission. The tab itself is empty for now; this ticket builds its frame, and the figures come in the next tickets.

This is the rule for how far each person sees, decided on the server every time. A system administrator sees every branch and can pick any of them. A branch administrator sees their own branch; the filter shows it as fixed, with a lock and the words Your scope. Someone who holds only Reports viewer sees the branches they belong to. Lantern support staff see the library system they chose. Anyone else cannot open the page. None of this is new data: it comes from the staff roster the system already sends. And nothing the browser sends can widen it; the page never even asks for a branch it is not allowed to have. The same rule now also drives the Users screen, which behaves exactly as before.

Here is the tab from the browser check, with three test branches in a developer sandbox. On the left, a system administrator: the Branch filter lists every branch, with All branches first, and the header says All branches in Fernbrook Libraries. On the right, a branch administrator for Harbour Street: there is no dropdown at all, just the branch as fixed text with a lock and Your scope, which is what the pilot systems asked for. The header names the branch. The empty state underneath is where the figures go in LNT-419.

Links are where scope is easiest to get wrong, so a link never fails and never shows too much. A link to a branch you can see opens with that branch chosen. A link to another branch shows no data at all: it says the branch is not in your scope, names the branch in the link and your own branch, and offers to open the same view for your scope or to go to your dashboard. That is the picture on the right. And a value in a link that does not apply, like a branch that does not exist, is cleared, with a notice saying which filter and why. The same rules will cover every filter the next tickets add.

Now someone who holds only Reports viewer, here belonging to Alder Park and Millbrook. Clicking Admin takes them straight to Insights, because Circulation is not open to them. The Branch filter offers All my branches and their two branches, and Harbour Street is not in the list at all. The other Admin tabs are still visible, as they are for desk staff, but each one says No permission. Hiding them was not in the ticket, and it would change what Workbench shows, so we left it for later.

Three decisions shaped this. First, the dashboard has its own way in. Opening the whole Admin area to Reports viewers would have opened Users and Settings with it, which is exactly what the new permission is meant to avoid. Second, one rule for every screen: the rule for which branches you see now lives in one place, and every dashboard screen the next tickets add will use it, so no single screen can apply it differently and let a branch administrator into another branch. Third, following the pilot systems' requirements, a branch administrator may compare their branch's totals with other branches, but never sees another branch's staff, patrons, holds or alerts. That split is built in now, ready for the comparison screens.

Every case was tried in a real browser against a sandbox, not only in automated tests, using three test branches and two test users. An Administrator clicking Admin still lands on Circulation, with Insights as a new tab. A system administrator picking a branch sees the header and the link follow. A branch administrator sees their branch fixed. A link to another branch shows no data and names both branches, and both buttons work. A made-up branch in a link is cleared with a notice. A Reports viewer lands on Insights with only their two branches, and gets No permission on Circulation and Users. The Users screen behaves exactly as before. The browser check also caught one small display bug, the Branch label overlapping its value, which is fixed. All automated tests pass.

What comes next: the tickets that fill the tab. LNT-419 adds the figures, the activity bands and the other filters, and puts the tab into Workbench's menu. LNT-420 is the loan distribution grid, where branch administrators compare with other branches. LNT-421 is the overdue and alerts tabs. All of them read through the rule from this ticket. Two things were left for later on purpose: hiding the Admin tabs a person cannot open, and the Workbench menu item, which waits until the tab has figures. And along the way we found that branch administrators can still read, and change, users in other branches through the Users side. That is older than this ticket; it is written up as tickets of its own, and the shared rule from this ticket makes it easier to fix.

For the engineers. The scope rule lives in the shared package as report-scope: a support operator gets the library system first, a caller with no record gets no branches, and then the three states of adminScopeBranchIds apply, with absent falling back to the caller's own branchIds. report-scope-loader reads the caller's own record with a consistent read. listReportBranches takes no arguments and is served by the existing staff-record-reader. The authorizer admits it through mayReadDashboard, which the next dashboard queries share. The tab is its own feature area, adminInsights, declared as a child of admin, and /admin redirects each caller to the first tab they may open. The Users screen uses the same rule, and a property test against a frozen copy of the old rule pins that nothing changed there. The decision record is ADR-0137.