Page the authorisation queue and count it on the server

The queue screen reads a window of requests rather than a page, because it does three things the wire cannot do a page at a time yet: it filters by class and by state, it counts each group for the figures on the buttons, and it orders the open requests and the answered tail as one list.

Every record list in the web reads one page from the server and states the server's total. The queue states its own window instead: it asks for 250 rows and warns above the table when the store holds more waiting. That is honest, and it is not the standard.

The standard exists so that a list never silently stops. Reading a window keeps the count truthful only as long as the queue is shorter than the window, and a tenant working a large book can pass 250 without noticing that the warning was the only sign.

The wire can nearly do it already. GET /api/queue/authorisations takes an offset and a limit, and the inbox answers a page of open requests with the total open count. What it cannot answer is the figure on each button: the number of requests in each state, in each class, across the whole queue. Those figures are what a person reads to decide whether the queue moved, so they cannot be dropped to gain paging.

Not designed here. The pieces that appear necessary:

• A count read: per state, per class, and per class within state, for the requests this person may decide. It is the aggregate of the rows the screen counts today.
• A queue read that pages the open requests and the answered tail as one ordered list, filtered by the class and the states the person chose, so the buttons become a server filter rather than a local one.
• The screen drawn from a server source, with the pager the other lists use, and the group filter passed in the address as every other list filter is.
• The answered tail needs its own total, or a stated window of its own, since a decision that aged out is not part of the count of what is waiting.

A tenant with ten thousand requests in the queue pages through them, the figures on the buttons match the store, and the screen says how many requests the filter matches in all rather than how many it happened to read.

• GET /api/queue/authorisations — the read that pages open requests and carries the open total.
• The operational authorisation queue — how the queue is organised and what the figures mean.

• Build the authorisation queue screen — the screen this serves.
• Classify a product type as flow or non-flow — the other read the queue's division depends on.