webstaff sortable holds pull list
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Evergreen ~2.11. Spin-off from bug #1437104.
Web staff client holds pull list should be sortable.
I previously posted a WIP branch:
This branch implemented sorting by making the pull list UI render itself via "flattener" API call, which allows for sorting on any field, plus limit/offset, at the server. I dusted the branch off today to see it still worked, minus some not-yet-implemented bits.
The one issue I encountered is that moving the holds data collection to flattener means the UI loses access to the hold queue position, since this data is calculated via separate API call (i.e. not in the database/IDL).
The queue position could potentially be added to the SQL used by the IDL "ahopl" class. It could also be fetched as an extra API call after the main list is rendered. Before we get into that, though, how critical is the queue position to the pull list? Is it more important than sort-ability and/or required for day 1?
Changed in evergreen: | |
milestone: | 2.next → 2.12-beta |
Changed in evergreen: | |
milestone: | 2.12-beta → 2.12-rc |
Changed in evergreen: | |
assignee: | nobody → Kathy Lussier (klussier) |
Changed in evergreen: | |
status: | Fix Committed → Fix Released |
I can't see any reason to expend any effort to make it available and it's certainly nothing to hold sorting up over. (I'm also really not fond of wasting more server round trips on that number.)