Web client: Billing Full Details Shows Blank Grid

I have replicated the described steps in Evergreen 3.3.2. The Grid for Bills is not blank and shows the expected amount. I have checked both Firefox and Chrome.
Probably the problem is specific for Evergreen 3.3.4 or (e.g.) is related to specific settings.

Confirming that this issue was introduced in 3.3.4, we did not see it on 3.3.3.

I suspect it is a side effect of the fix for bug 1790169. I don't see any other changes between 3.3.3 and 3.3.4 that would cause it.

TypeError: Cannot read property 'target_copy' of null
at bills.js:933

The target_copy exception is a red herring. I've narrowed it down to the grid.dataProvider.refresh(); statement in configLoadPromise

possible fix here: collab/phasefx/lp1846038 @ working/Evergreen.git

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=62d2b12037ddf7431596847f548a107d6c679bf1

Works for me. Signoff here: user/rogan/lp1846038_billing_full_details

Grabbed this a little bit ago hoping for an easy win, but still looking at it cross-eyed. It appears to work, but does anyone know why this works? That's what I'm looking into, but would welcome some education.

It is a bit of voodoo to me, but it was my first instinct for a solution and it worked. Something isn't settled until that execution thread finishes, and that timeout kicks the refresh onto a new thread.

I worked on this a bit yesterday with Bill, and we got off in the weeds on some ancillary bugs, but now that I can finally reliably test columns sorting/saving, I'll push a branch soon, along with some details of what I learned. Spoiler alert: I think we don't need the line at all.

Okay, so Bill gave me a lesson in why $timeout() helps in general, which seemed worth passing along in brief, even if just as review. JavaScript is processed as an event loop, and adding a $timeout(), even if no delay is specified, still tells the execution queue to process the contained function on the *next* event loop iteration. This guarantees anything already in the call stack will finish before the $timeout-wrapped code gets a chance to run. It is generally preferred to chain execution dependencies and maintain order via promises, but $timeout() is simple and can get you out of jam. (If I have oversimplified, please comment!)

Fortunately, in this case, I think the jam doesn't actually exist. As Jeff D. pointed out, the changes meant to fix column sort saving included the problematic line, but I wonder if this was included inadvertently in the WIP branch, as there is no mention of it, and it actually appears unnecessary in testing and debugging. Here is some more light reading from the commit message:

Bug LP#1790169 added the ability to save sorting configuration, but it also added an additional grid refresh to the configuration load. This breaks grid loading.

The expected flow is for is to first load any existing configuration, then do the first collect() for the grid. This refresh() call adds potentially a second collect() which may run earlier than it should,
and overall does not seem necessary.

To test:

(Make sure you are testing on current master or rel_3_3/3_4, or you will (like me) hit related bugs which have been fixed. Also, some grids (especially circ) do not honor sort for other reasons, so avoid those for now.)

1) Find a grid which has a typical get() process. Suggestion would be a basic auto grid, such as full bill details, https://localhost/eg/staff/circ/patron/11/bill/43/details .
2) Set a sort value you can see, then *save* the configuration.
3) Before the patch, billing details grid doesn't load. After patch, grid loads and still honors the defined sort.

Since I got off in the weeds on the circ sorting, I will also be opening a bug with branch shortly in that area.

Forgot to include the branch:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbwells/lp1846038_remove_extra_grid_refresh

working/user/dbwells/lp1846038_remove_extra_grid_refresh

Double-checked with Galen, and his recollection was that this would have been for initial page loads of sort order priority, and my testing is that that particular case also still works without it. I think we're good.

Tested and confirmed, this fixes the blank grid while honoring the sort setting. Here's my sign-off branch:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/rsteed/lp1846038_remove_extra_grid_refresh

Also, I found another grid that is affected by this bug (though it doesn't allow saving a sort priority):

Local Admin -> Item Alert Types
(localhost/eg/staff/admin/local/config/copy_alert_types)

I like it! Picked to master back through rel_3_2.

Thanks, all!