Curbside - Appointments not in order

Bug #1902739 reported by Josh Stompro
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Evergreen
New
Undecided
Unassigned

Bug Description

EG 3.3

Hello, we are seeing the appointment slots being listed out of order in the "to be staged" and "staged and ready" interfaces.

What I've observed so far is that one appointment will show up out of order as the top spot, even when their are slots earlier than it. The rest of the appointments show up in order.

I've confirmed that "open-ils.curbside.fetch_staged" is returning the results in the same order that they are being displayed.

fetch_staged seems to include a sort on the slot column, which looks like it should return results in the correct order.

select * from action.curbside where delivered is null order by slot;
id|patron|org|slot|staged|stage_staff|arrival|delivered|delivery_staff|notes
208|127625|102|2020-11-03 10:00:00-06|2020-11-03 09:05:04.908595-06|1||||Josh Test
180|179297|102|2020-11-03 10:30:00-06|2020-11-02 12:48:03.329343-06|185532||||
210|128454|102|2020-11-03 10:30:00-06|2020-11-03 09:05:06.394027-06|1||||Another Test appointment
170|184860|102|2020-11-03 11:00:00-06|2020-11-03 09:13:00.709093-06|112781||||Black Chrysler minivan

But the client is displaying the results in this order. (first two results swapped).

id|patron|org|slot|staged|stage_staff|arrival|delivered|delivery_staff|notes
180|179297|102|2020-11-03 10:30:00-06|2020-11-02 12:48:03.329343-06|185532||||
208|127625|102|2020-11-03 10:00:00-06|2020-11-03 09:05:04.908595-06|1||||Josh Test
210|128454|102|2020-11-03 10:30:00-06|2020-11-03 09:05:06.394027-06|1||||Another Test appointment
170|184860|102|2020-11-03 11:00:00-06|2020-11-03 09:13:00.709093-06|112781||||Black Chrysler minivan

I'm wondering if the _flesh_and_emit_slots function is reordering them?

Or maybe the web client is doing it's own sorting later?

This causes a problem because when staff see the first staged and ready appoint is for X time, they are not expecting earlier appointments to be after that appointment in the list. It causes a general distrust of the results and the feeling like they have to look through all the staged appointments just in case there are more out of order.

We have locally adjusted the curbside module to show 72 Hours of appointments instead of 2 x slot length ahead slots. We don't have the staff to have people dedicated to curbside, so staff prefer to stage appointments ASAP vs only an hour ahead of time.

Josh

Tags: curbside
Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

Hello, Just had another instance of this pop up, this time in the fetch_to_be_staged results.

I've noticed that this seems to happen to entries with 19+ holds, so it may be related to the number of holds somehow.

The cstore call does seem to return the info in the correct order.

request open-ils.cstore open-ils.cstore.direct.action.curbside.search.atomic {"org":"102","slot":{"<=":"2020-11-08T20:09:41+0000"},"staged":null},{"flesh_fields":{"acsp":["patron","stage_staff"],"ausp":["standing_penalty"],"au":["card","standing_penalties"]},"limit":25,"order_by":{"acsp":"slot"},"flesh":3}

but then calling
request open-ils.curbside open-ils.curbside.fetch_to_be_staged "AuthID",102, 25, 0

results in the incorrect order.

Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

Hmm, calling

request open-ils.curbside open-ils.curbside.fetch_to_be_staged.atomic "AuthID",102, 25, 0

does give me the correct order, while the non-atomic call stays out of order. So maybe the web staff client code should be using the atomic version?

Josh

tags: added: curbside
Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

Ah, I get it now. open-ils.curbside open-ils.curbside.fetch_to_be_staged streams the results back, so if it takes longer for an appointment with 19+ holds to get sent back, it would be out of order.

_flesh_and_emit_slots makes use of $conn->respond() to send appointments back asynchronously.

So the grid for displaying results cannot just display them in returned order since that may not be the correct order for showing to staff. Is this just a normal aspect of using a non atomic call, not being able to expect a certain result order?

So... just need to figure out how to sort a grid.

Josh

Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

I tried setting a setSort function, but that didn't make any difference.

    $scope.gridControls = {
       setSort : function () { return [ { 'slot.slot' : 'desc'}] }

    };

Setting the eg-grid sort option to enabled sets the grid headers to clickable, but no sorting takes place when clicking the heading links.

I also tried switching to the .atomic call and that broke the interface, so that isn't an easy fix.

I'm not sure how to get the grid sorting to work, if anyone can give me a hint of where to look for an example, I can keep looking into this. But otherwise I'm stumped.
Josh

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.