Webstaff: Claims returned/neverchecked clobbered by edit in alt tab
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Fix Released
|
Medium
|
Unassigned | ||
2.12 |
Fix Released
|
Medium
|
Unassigned |
Bug Description
Bug #929172 take II -- This time it's personal (and webstaff).
Steps to reproduce:
1. Open a patron in the webby that has items checkout out: Tab 1.
2. Open a second tab to the edit interface for the same patron (e.g. ctrl-click the Edit tab link in Tab 1): Tab 2.
3. In Tab 1, mark an item as claims returned.
4. Confirm actor.usr.
5. In tab 2, note the claims_
6. Confirm the actor.usr.
One proposed but abandoned fix from bug #929172 that likely would have prevented this is to ensure the affected patron's last_xact_id value is updated when a claims returned or never-checked-out event occurs. With that, the secondary save will fail and force a page reload.
Normally, last_xact_id is set from open-ils.
Changed in evergreen: | |
assignee: | nobody → Bill Erickson (berick) |
Changed in evergreen: | |
assignee: | nobody → Galen Charlton (gmc) |
Changed in evergreen: | |
status: | Confirmed → Fix Committed |
Changed in evergreen: | |
status: | Fix Committed → Fix Released |
Another option that would address this is making use of incremental updates rather than full. As it is now, if you only change a single field and click Save, (almost) every field has its value specified in the UPDATE statement that's sent to the db. Changing that still wouldn't make it a *good* idea to modify the same record in multiple tabs simultaneously but it would make data trampling issues a lot more rare.
(Not saying kicking cstore/pcrud isn't a fine way to take care of it at the moment; just raising the question since I don't know if it's come up before.)