Workstation setting cat.copy.defaults not sticky

Bug #1812900 reported by Elaine Hardy on 2019-01-22
70
This bug affects 13 people
Affects Status Importance Assigned to Milestone
Evergreen
Medium
Unassigned
3.1
Medium
Unassigned
3.2
Medium
Unassigned

Bug Description

The Print Item Labels on Save & Exit check box in the Holdings editor Defaults is not sticky across bibliographic records. If you reopen the Holdings editor for the same bib record, the box is checked and you can print on save & exit but it will not be checked in another bib record.

We are live today with 3.2.2. Cataloger reports it was sticky in 3.0.2

description: updated
Elaine Hardy (ehardy) wrote :

We have found that many of the settings under the Defaults tab do not always stick when unchecked. So far, we have found those that don't stick are:

Deposit
Deposit amount
Floating
Quality
Acquisition Cost

The defaults will stick for a record or two and then will reset.

Some people see this behavior only on Firefox and others on both Firefox and Chrome. For me I never have a problem with Chrome but do when logged in through Firefox.

Elaine Hardy (ehardy) wrote :

See additional comments with duplicate https://bugs.launchpad.net/evergreen/+bug/1818916

Elaine Hardy (ehardy) wrote :

While Michele reports that they are seeing this with the use of add holdings, we are seeing the settings revert to default both with add holdings and using the Actions menu at holdings view. Some users never see the settings revert to default and others never have the settings save beyond one or two records (settings will save for a few records and then revert to defaults)

summary: - Print item labels on save & exit not sticky
+ Workstation setting cat.copy.defaults not sticky
Elaine Hardy (ehardy) wrote :

Edited title to be more inline with issue

Changed in evergreen:
status: New → Confirmed
importance: Undecided → Medium
Andrea Neiman (aneiman) wrote :

Adding a note that we have encountered this with the "Allow Call Number attributes in Copy Templates" checkbox as well. It sporadically un-sticks, and I haven't been able to trace a reason.

Janet Schrader (jschrader) wrote :

We have found that "Always show holding default pane", "Use checkdigit", and "Auto-generate barcodes" do not stay checked.
The latter two make it harder for libraries to add multiple copies because there is no indication why entering the first barcode doesn't auto-generate the next ones. It's also problematic because without "use checkdigit" there is no warning that a barcodes is invalid .
Because the "holdings default pane' can also be toggled on and off using a button on the item record screen, turning it on with the button keeps it on even if the checkbox is unchecked.

Release 3.2.4
Chrome browser

Galen Charlton (gmc) on 2019-04-19
Changed in evergreen:
milestone: none → 3.3.1
assignee: nobody → Galen Charlton (gmc)
Galen Charlton (gmc) wrote :

The problem has been observed in 3.1.11 as well.

A patch is available for testing in the working branch user/gmcharlt/lp1812900_fix_save_volcopy_defaults -

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

tags: added: pullrequest
Galen Charlton (gmc) wrote :

I note that the patch for bug 1793196 that moved one of the calls to $scope.fetchDefaults() seemed to caused (or revealed) the issue between 3.1.10 and 3.1.11, but that doesn't account for why folks also saw the problem in 3.2.2.

tags: added: regression
Andrea Neiman (aneiman) on 2019-05-14
tags: added: ws-settings
Changed in evergreen:
milestone: 3.3.1 → 3.3.2
Galen Charlton (gmc) on 2019-05-24
Changed in evergreen:
assignee: Galen Charlton (gmc) → nobody
Remington Steed (rjs7) wrote :

I tested Galen's branch and it worked as expected. And his code and explanation make sense to me. Here's my signoff.

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

tags: added: signedoff
Changed in evergreen:
assignee: nobody → Jason Stephenson (jstephenson)
Jason Stephenson (jstephenson) wrote :

Guess I should add that we're testing this at CW MARS. Don't let the fact that I've assigned the bug to myself stop you from looking at it or even pushing it before I get around to it. It might be a few days/weeks. We've got a lot going on right now.

John Amundson (jamundson) wrote :

I tested this with our local data at CW MARS, and it worked well in my testing. Adding my signoff, too. I have tested this code and consent to signing off on it with my name, John Amundson, and my email address, <email address hidden>.

Jason Stephenson (jstephenson) wrote :

It also works for Janet Schrader at CW MARS, so I've added our sign offs and pushed the patch to master, rel_3_3, rel_3_2, and rel_3_1.

Thanks, everybody!

Changed in evergreen:
assignee: Jason Stephenson (jstephenson) → nobody
status: Confirmed → Fix Committed
Janet Schrader (jschrader) wrote :

Thanks, Jason. Yes, this worked in my testing also, looking forward to seeing it live.
I'll be official and add my signoff with my name, Janet Schrader and my email address, <email address hidden>.

Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers