https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31187 Bug 31187 depends on bug 30909, which changed state. Bug 30909 Summary: Regression, Permanent shelving location is always updated when editing location VIA ADDITEM.PL if both are mapped to MARC fields https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30909 What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to master |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31187 Bug 31187 depends on bug 30909, which changed state. Bug 30909 Summary: Regression, Permanent shelving location is always updated when editing location VIA ADDITEM.PL if both are mapped to MARC fields https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30909 What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |--- -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31187 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31187 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #2 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- It seems we keep running into this kind of issue in some variations. Actually, I am also confused: When do we want to update the permanent item location and when do we not? My impression was that whenever the location is updated and the value is not CART or PROC, the we'd also like to make the permanent location match. It's been moved to a new location, so if it was checked out/checked in, set to CART, it should be able to go back to the new location. But now it feels a bit like we might have different uses of the field depending on configuration maybe? And if we do... should we do that? And if so, is this documented somewhere? Do we expect people to always set both manually if they are linked to MARC fields? What if $k was set to hidden in the item form? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31187 Andrew Fuerste-Henry <andrewfh@dubcolib.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=33301 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31187 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff --- Comment #4 from Nick Clemens <nick@bywatersolutions.com> --- (In reply to Katrin Fischer from comment #2)

It seems we keep running into this kind of issue in some variations.

This is why I add a test here, to prevent future breakage

Actually, I am also confused: When do we want to update the permanent item location and when do we not?

If it is visible in the form, but has no value then we want to preserve the original value and not set it to location

My impression was that whenever the location is updated and the value is not CART or PROC, the we'd also like to make the permanent location match. It's been moved to a new location, so if it was checked out/checked in, set to CART, it should be able to go back to the new location.

This was the case originally, however, it became possible to add both to the editors and set individual values.

But now it feels a bit like we might have different uses of the field depending on configuration maybe? And if we do... should we do that? And if so, is this documented somewhere?

It may not be documented, but it has become a fairly common practice. I think we should document and support it.

Do we expect people to always set both manually if they are linked to MARC fields? What if $k was set to hidden in the item form?

If mapped and hidden, then it operates where a location update always updates both. If exposed in the form, i.e. we receive a value in the scripts, then we need to assess if the value is blank and preserve pre-edited value rather than matching to location -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31187 --- Comment #6 from Andrew Fuerste-Henry <andrewfh@dubcolib.org> --- (In reply to Katrin Fischer from comment #5)

Could we imagine making this more solid somehow if people really need it? What's the use case? Can you still use CART/PROC or is this exclusive?

I'm not against moving this into a real feature rather than a possible modification. The use case here is a temporary shelving location to show that an item has been placed in a display. Items are pulled from the stacks and put in a display, the shelving location is set to DISPLAY so staff/patrons know the item is available but not at its usual spot. If those items are checked out, we don't want to try to get them back to the display on return -- that's too much staff hassle and likely the display will have been changed out before the item is returned anyway. This workaround makes it so that when the item is returned its shelving location automatically reverts to its regular value. This workflow does not impact the usability of CART or PROC. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31187 --- Comment #8 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I am ok to continue discussion elsewhere and it's not the ideal way for features to develop - but it happens, I just want to deal with it in a saner way to avoid having more bugs like this :) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31187 Andrew Fuerste-Henry <andrewfh@dubcolib.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31187 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA CC| |jonathan.druart+koha@gmail. | |com --- Comment #11 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- FAIL forbidden patterns: tab char -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31187 --- Comment #12 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 150213 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=150213&action=edit Bug 31187: (follow-up) Fix whitespace -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31187 --- Comment #14 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Added a patch to add a next, it seems safe to have it (no idea if it's really needed). Also adjusting the 'reset' call to make it looks like other similar statements. I am not sure we are doing things correctly, the number of items modified displayed in the report of the batch tool won't be correct as we are considering each items of the batch is modified. Not enough brain power for now to go further with this one... -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31187 --- Comment #16 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- I am not sure we actually need the modified++ you have added, do we? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31187 --- Comment #18 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Please do, squash everything. I think we also need more tests... -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31187 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31187 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|katrin.fischer@bsz-bw.de |testopia@bugs.koha-communit | |y.org Status|Signed Off |Failed QA --- Comment #20 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- With this patch applied, I think we now have a regression for the other use case: select kohafield from marc_subfield_structure where tagfield = 952 and kohafield like "%perm%"; = empty, no results I haven't linked the subfield in the frameworks. But: * location and permanent location are both = FIC * Edit location (c) in the item editor: both are now GEN * Batch mod the same item. Set location (c) to FIC. * We now have location = FIC / permanent.locaton = GEN The item editor and the batch mod should behave the same way, shouldn't they? How do you check on the link? I still had k set to the auth_value, but I think that should not matter. It works as expected without the patch applied. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31187 --- Comment #21 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 150597 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=150597&action=edit Bug 31187: (follow-up) Check if input in form, not if values passed This patch updates the check to see if there was a form input present, not if a value was passed. $attr contains an item colum @form_attr contains the form inputs for the attribute @values (renamed from @v) contains the uniq values passed in to the form We want to know if permanent_location is in the form, not if it had values, to know if we should preserve the DB value To test: 1 - Apply patches 2 - Make sure permanent_location is not mapped to a marc field 3 - Batch edit an item, changing shelving location 4 - Confirm both location and permanent_location are changed -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31187 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31187 Rhonda Kuiper <rkuiper@roundrocktexas.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rkuiper@roundrocktexas.gov --- Comment #24 from Rhonda Kuiper <rkuiper@roundrocktexas.gov> --- I wanted to share how our library uses items.permanent_location and items.location to show items in display locations. We have both fields mapped to MARC fields (items.location -> 'c' and items.permanent_location -> 'C'). An example of our workflow is: We want to create a new display of children's book. We batch modify the items.location field for all the items on the new display to show '2ND FLOOR DISPLAY' and the items.permanent_location remains unchanged showing the location of the collection it is usually shelved with. We do not mark/sticker the items that are going on display to save staff time. Little Johnny comes in and sees a book on the display that he wants. He checks it out (Nothing changes in the location fields). Later, Little Johnny returns the book and it is checked in. At this time the items.location field is set to CART (and the items.permanent_location field still remains unchanged). Because we have not marked/stickered the item, public services staff shelve the item in its usual location, not the display location. Some time later the items.location field is updated from CART to whatever was in the items.permanent_location which is still the original location of the item which is where it got shelved. This workflow keeps the items physical shelving location and the shelving location in Koha matching. Currently this workflow works if you use the item editor but when using batch modification, the permanent_location gets updated with the location field. Item editor and batch modification should work the same. -- You are receiving this mail because: You are watching all bug changes.