Bug 14962 - Temp Shelving Location
Summary: Temp Shelving Location
Status: Needs Signoff
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low enhancement
Assignee: Jacob O'Mara
QA Contact: Testopia
URL:
Keywords:
: 30910 31168 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-10-05 22:13 UTC by Christopher Brannon
Modified: 2025-12-05 22:52 UTC (History)
16 users (show)

See Also:
GIT URL:
Initiative type: ---
Sponsorship status: Sponsored
Comma delimited list of Sponsors:
Crowdfunding goal: 0
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments
Bug 14962: On Display code for C4 modules (10.89 KB, patch)
2025-12-05 14:51 UTC, Jake Deery
Details | Diff | Splinter Review
Bug 14962: On Display code for BackgroundJobs (12.65 KB, patch)
2025-12-05 14:51 UTC, Jake Deery
Details | Diff | Splinter Review
Bug 14962: On Display code for REST API (51.25 KB, patch)
2025-12-05 14:51 UTC, Jake Deery
Details | Diff | Splinter Review
Bug 14962: On Display code for existing Koha modules (9.95 KB, patch)
2025-12-05 14:51 UTC, Jake Deery
Details | Diff | Splinter Review
Bug 14962: On Display code for new Koha modules (13.96 KB, patch)
2025-12-05 14:51 UTC, Jake Deery
Details | Diff | Splinter Review
Bug 14962: On Display config changes for Vue (2.01 KB, patch)
2025-12-05 14:51 UTC, Jake Deery
Details | Diff | Splinter Review
Bug 14962: On Display changes to build suite (1.80 KB, patch)
2025-12-05 14:51 UTC, Jake Deery
Details | Diff | Splinter Review
Bug 14962: On Display config changes for tables (1.07 KB, patch)
2025-12-05 14:51 UTC, Jake Deery
Details | Diff | Splinter Review
Bug 14962: On Display code for API Clients (10.99 KB, patch)
2025-12-05 14:51 UTC, Jake Deery
Details | Diff | Splinter Review
Bug 14962: On Display code for new Vue app (47.14 KB, patch)
2025-12-05 14:51 UTC, Jake Deery
Details | Diff | Splinter Review
Bug 14962: On Display code for Intranet scripts & templates (99.43 KB, patch)
2025-12-05 14:51 UTC, Jake Deery
Details | Diff | Splinter Review
Bug 14962: On Display code for OPAC scripts & templates (4.17 KB, patch)
2025-12-05 14:51 UTC, Jake Deery
Details | Diff | Splinter Review
Bug 14962: On Display changes for SQL (5.59 KB, patch)
2025-12-05 14:51 UTC, Jake Deery
Details | Diff | Splinter Review
Bug 14962: On Display atomicupdate - DO NOT PUSH (10.96 KB, patch)
2025-12-05 14:51 UTC, Jake Deery
Details | Diff | Splinter Review
Bug 14962: On Display svc API changes (4.29 KB, patch)
2025-12-05 14:51 UTC, Jake Deery
Details | Diff | Splinter Review
DBIC - DO NOT PUSH (15.86 KB, patch)
2025-12-05 14:51 UTC, Jake Deery
Details | Diff | Splinter Review
reword! test suite for bug_14962 (58.41 KB, patch)
2025-12-05 14:52 UTC, Jake Deery
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Brannon 2015-10-05 22:13:12 UTC
Would like to see a new location field added to the items table, like TEMPLOC.  This field would be ignored if blank, but if populated it's data would be used instead of the data in the LOCATION field.

The idea is, if you are placing items in a temporary location, like a display, you can actually list the location, but not loose the permanent location.  Then, when it comes time to move the item back to its regular location, you can simply clear the TEMPLOC field.

Christopher
Comment 1 David Cook 2015-10-05 22:20:10 UTC
Doesn't this already exist with the "location" field?

If you're losing the permanent location, it could be that there's a bug...
Comment 2 Christopher Brannon 2015-10-05 22:26:00 UTC
(In reply to David Cook from comment #1)
> Doesn't this already exist with the "location" field?

Sort of, but it is tied in with the PROC and CART features.  How would you retain the permanent location, the temp location of the display, and the PROC/CART locations?

I guess if you didn't want the item going back to display, that would work, but what if you have a special holiday or themed collection residing somewhere for a while?  After the first time out it goes back to its permanent location.

Christopher
Comment 3 David Cook 2015-10-05 22:46:24 UTC
(In reply to Christopher Brannon from comment #2)
> (In reply to David Cook from comment #1)
> > Doesn't this already exist with the "location" field?
> 
> Sort of, but it is tied in with the PROC and CART features.  How would you
> retain the permanent location, the temp location of the display, and the
> PROC/CART locations?
> 
> I guess if you didn't want the item going back to display, that would work,
> but what if you have a special holiday or themed collection residing
> somewhere for a while?  After the first time out it goes back to its
> permanent location.
> 
> Christopher

Ahh, I see what you're saying. 

I've always found items in Koha to be a bit funny/confusing. There's a permanent_location, location, ccode (collection code). 

Personally, I would think the collection would be synonymous with shelving location, and that location would be more like "status" (in processing, on cart, on shelf, etc). 

If anything, I would think it would make more sense to have ccode and location/status. Maybe permanent_ccode if you wanted to designate the "true" collection for an item, and then have an ability to add it to temporary collections without losing track of the original collection.

--

You might also be able to use the rotating collections feature: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8836

Once upon a time, I worked at a multilingual library where we had books in 29 different languages each with their own set of collections. Every so often, a small rotating collection would be created from some of these books, it would be sent around the province (in Canada) to other libraries before returning home to our library where the books would go back to their original collection.

In this case, you wouldn't have to transfer the collection to another library. You could use it as a temporary collection. 

That's theoretical though. I haven't used this feature in Koha... worth experimenting or talking to Kyle Hall about it, I imagine.
Comment 4 Katrin Fischer 2015-10-05 22:51:12 UTC
I think a lot of libraries use the collection with something unrelated to the location in the library - for example it could be a special donation they want to highlight, that was shelved with the other books. 

I think the rotating collection an item belongs to is currently not visible in the OPAC, but might be something that could be added. A problem might be searching for it - that would be easier to solve if it was a field in the item record. Hm.
Comment 5 David Cook 2015-10-05 22:58:15 UTC
(In reply to Katrin Fischer from comment #4)
> I think a lot of libraries use the collection with something unrelated to
> the location in the library - for example it could be a special donation
> they want to highlight, that was shelved with the other books. 
> 
> I think the rotating collection an item belongs to is currently not visible
> in the OPAC, but might be something that could be added. A problem might be
> searching for it - that would be easier to solve if it was a field in the
> item record. Hm.

Fair enough.

I suppose my concern is that there are already 43 columns in the items table, and we're running out of conventional subfield codes in the 952. I suppose we could start using capital letters or any of the other interesting things available in the following range:

[\dA-Za-z!"#$%&'()*+,-./:;<=>?{}_^`~\[\]\\]{1}
(http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd)
Comment 6 Katrin Fischer 2015-10-06 05:48:53 UTC
Maybe this could work like the course reserves? The former location is stored separate from the item data until the item is moved back
Comment 7 Christopher Brannon 2017-02-14 18:20:07 UTC
Expanding on this topic, I think there are several things to be considered here:

* Setting up temporary locations, aside from cart, without loosing the permanent location.
* Keeping quick access to all locations:
Comment 8 Christopher Brannon 2017-02-14 18:36:26 UTC
Sorry, hit the wrong key.  Let me try again:

Expanding on this topic, I think there are several things to be considered here:

* Setting up temporary locations, aside from cart, without loosing the permanent location.
* Keeping quick access to all locations:
    - Maybe only show the most relevant, but hovering over it would display all locations.  (i.e. show CART, but when hovering, show the TEMPLOC if exists, and show the permanent location).  Showing only the most relevant location would keep the real estate use low, but keep this information hand and accessable.
    - Keeping this information handy is important, as it would give way to custom alerts and sounds when items in temporary locations need to be shelved elsewhere.
* Optionally setup temporary location expiration interval (i.e. 30 days): set it so Koha removes items from this temp location at a designated time, if desired, so staff don't have to touch records.  When the item is set with the temp location, a temp location time stamp is recorded.  When the item is checked in and is past the interval for that particular location, the temp location and it's date are removed.
* Ideally I think this information should be kept in the item record.  Yes, another table could be used, but it is not likely that an item is going to have more than one temp location, unless the CART location and the temp location are stored in a unified table.  Then perhaps that information could all reside in a separate single table.  But having locations with different natures in the same table might prove problematic.
* Have the option with each temporary location for a popup and sound event.

Those are just some ideas.  I think it is worth exploring.  Many libraries display books, and this would significantly help with the workflow of these items, in my opinion.
Comment 9 Christopher Brannon 2018-03-06 15:46:57 UTC
The biggest issue for us on items on display is handling.  We can certainly define locations for displays.  And Koha now has the ability to automatically update information (like reset a location) after a prescribed length of time.  That was one of the troublesome areas that Koha has solved (thank you!).  The problem still at hand is how to get staff to know where to shelve the item if it is supposed to be on display.  When an item is checked in, unless there is some special marking on the book (which really defeats the purpose of Koha automatically updating locations so staff don’t have to), how do staff know to shelve it in the display rather than its normal location?  The best answer would be to have a popup for items in specific locations on check in.  This would alert staff, and they would either place the item in a special pile or place a bookmark in it or something at that time so they know to shelve it elsewhere.

As long as we have to manually process the book in some way in order to keep it in a special location, it remains a chore that current automated processes that Koha has can’t handle quite yet.  We are close, but there are still some minor kinks to work out.

Ideally, it would be great if you had a display module to check items in on.  It would ask where you want to display the item, and for how long.  Then the module would temporarily move the item to the new location, setup a rule to change it back after the time is up, and would alert staff of the temporary location when checked in at the home location.
Comment 10 Owen Leonard 2018-03-06 16:05:14 UTC
See also: Bug 6615 - Add shelving location option to transfers page. I think it would be useful to be able to transfer books from one shelving location to another without granting staff batch item modification permission.
Comment 11 Katrin Fischer 2023-07-04 07:29:47 UTC
Is this similar/same as bug 31168?
Comment 12 David Cook 2023-07-05 05:09:06 UTC
(In reply to Katrin Fischer from comment #11)
> Is this similar/same as bug 31168?

Seems like a duplicate to me.
Comment 13 Christopher Brannon 2023-07-05 14:32:33 UTC
*** Bug 31168 has been marked as a duplicate of this bug. ***
Comment 14 Alexander Wagner 2024-03-07 13:29:19 UTC
First I'd second (Katrins comment)(https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14962#c4) that collections are something different than locations. They may coincide, but they don't have to.

Being pointed to this bug, I wonder if there is indeed yet another column required. The current mappings in `UpdateItemLocationOnCheckin` for some reason change both: `items.location` _and_ `items.permanent_location`. Just for `CART` and `PROC` they work on `items.location` only.

I wonder why they don't work on `items.location` only all the time, especially as I have `_PERM_` referring to `items.permanent_location`. It could just clear `items.location` so the item is back at the permanent location.

It might be, that there is only a way lacking to actually _set_ `items.location` and only `items.location` to the value required. Say, if I could set `items.location` to `DSP` (or whatever LOC value) one is already there, adding a rule that clears `DSP` upon item check in. Or alternatively, if items on display should stay on display even after a check in I'd leave this rule and at some point explicitly clear `item.location`. Both could also be done by some cron-job.
Comment 15 Kristi Krueger 2024-03-15 13:47:35 UTC
Re: Christopher's earlier comment, "Ideally, it would be great if you had a display module to check items in on.  It would ask where you want to display the item, and for how long.  Then the module would temporarily move the item to the new location, setup a rule to change it back after the time is up, and would alert staff of the temporary location when checked in at the home location."

We would be interested in using something similar for a set of titles that would stay within a display/shelf area in a particular branch for a set amount of time. Once the time is up, they'd be part of the general catalog.
Comment 16 Andrew Fuerste-Henry 2024-04-18 14:55:39 UTC
*** Bug 30910 has been marked as a duplicate of this bug. ***
Comment 17 Andrew Fuerste-Henry 2024-04-18 15:04:45 UTC
(In reply to Alexander Wagner from comment #14)
> It might be, that there is only a way lacking to actually _set_
> `items.location` and only `items.location` to the value required. Say, if I
> could set `items.location` to `DSP` (or whatever LOC value) one is already
> there, adding a rule that clears `DSP` upon item check in. Or alternatively,
> if items on display should stay on display even after a check in I'd leave
> this rule and at some point explicitly clear `item.location`. Both could
> also be done by some cron-job.

Over on Bug 30910, I suggested making it possible to define which shelving locations are automatically applied to permanent_location when setting regular location.

I'm taking this out of In Discussion. There seems to be a strong consensus that it would be useful. The only argument against it I see here is that we're running out of characters with which to designate 952 subfields --- this feature need not add a field in the items table, and even if it does that field need not be tied to a MARC subfield.
Comment 18 Jacob O'Mara 2025-09-08 10:29:09 UTC
We have a version of this now written and in testing with some of BWS's partners. Will upload to BZ after they confirm functionality
Comment 19 Jacob O'Mara 2025-11-26 15:21:42 UTC
Following feedback from BWS and partners, we've been doing some follow ups to this. That code is now written and is currently being squashed ready for upstreaming. Should be here ready for sign off in the next week or so.
Comment 20 Jake Deery 2025-12-05 14:51:08 UTC
Created attachment 190216 [details] [review]
Bug 14962: On Display code for C4 modules

This patch adds code for the On Display module, found in the C4 modules.
Please see the test files commit for instructions on how to test this
bundle of patches.
Comment 21 Jake Deery 2025-12-05 14:51:11 UTC
Created attachment 190217 [details] [review]
Bug 14962: On Display code for BackgroundJobs

This patch adds code required to make BackgroundJobs accept and process
batch addition and removal of items to and from displays.
Please see the test files commit for instructions on how to test this
bundle of patches.
Comment 22 Jake Deery 2025-12-05 14:51:14 UTC
Created attachment 190218 [details] [review]
Bug 14962: On Display code for REST API

This patch adds all the various API endpoints, and modifies a few
existing API endpoints, in preparation for the On Display Vue app
Please see the test files commit for instructions on how to test this
bundle of patches.
Comment 23 Jake Deery 2025-12-05 14:51:17 UTC
Created attachment 190219 [details] [review]
Bug 14962: On Display code for existing Koha modules

This patch adds code for the On Display module, found in the existing
Koha modules.
Please see the test files commit for instructions on how to test this
bundle of patches.
Comment 24 Jake Deery 2025-12-05 14:51:21 UTC
Created attachment 190220 [details] [review]
Bug 14962: On Display code for new Koha modules

This patch contains new code found in the On Display module. Be sure to
rebuild the DBIC modules, prior to pushing.
Please see the test files commit for instructions on how to test this
bundle of patches.
Comment 25 Jake Deery 2025-12-05 14:51:24 UTC
Created attachment 190221 [details] [review]
Bug 14962: On Display config changes for Vue

This patch contains config changes to enable the new On Display Vue app
to work.
Please see the test files commit for instructions on how to test this
bundle of patches.
Comment 26 Jake Deery 2025-12-05 14:51:27 UTC
Created attachment 190222 [details] [review]
Bug 14962: On Display changes to build suite

This patch contains the essential changes required to get Koha to build
the correct JavaScript and Vue modules for the new On Display module.
Please see the test files commit for instructions on how to test this
bundle of patches.
Comment 27 Jake Deery 2025-12-05 14:51:30 UTC
Created attachment 190223 [details] [review]
Bug 14962: On Display config changes for tables

This patch adds the Display column to a number of tables, ready for the
On Display module.
Please see the test files commit for instructions on how to test this
bundle of patches.
Comment 28 Jake Deery 2025-12-05 14:51:34 UTC
Created attachment 190224 [details] [review]
Bug 14962: On Display code for API Clients

This patch adds the required API clients for use with the On Display
module.
Please see the test files commit for instructions on how to test this
bundle of patches.
Comment 29 Jake Deery 2025-12-05 14:51:38 UTC
Created attachment 190225 [details] [review]
Bug 14962: On Display code for new Vue app

This patch adds the On Display Vue app. Please make sure you rebuild
your JavaScript prior to testing this patch.
Please see the test files commit for instructions on how to test this
bundle of patches.
Comment 30 Jake Deery 2025-12-05 14:51:42 UTC
Created attachment 190226 [details] [review]
Bug 14962: On Display code for Intranet scripts & templates

This patch makes the necessary changes to the Intranet to make sure
effective locations, collection codes, and branches are correctly
displayed.
Please see the test files commit for instructions on how to test this
bundle of patches.
Comment 31 Jake Deery 2025-12-05 14:51:45 UTC
Created attachment 190227 [details] [review]
Bug 14962: On Display code for OPAC scripts & templates

This patch makes the necessary changes to the OPAC to make sure
effective locations, collection codes, and branches are correctly
displayed.
Please see the test files commit for instructions on how to test this
bundle of patches.
Comment 32 Jake Deery 2025-12-05 14:51:49 UTC
Created attachment 190228 [details] [review]
Bug 14962: On Display changes for SQL

This patch contains the required schema changes that will enable On
Display to function as a new module.
Please see the test files commit for instructions on how to test this
bundle of patches.
Comment 33 Jake Deery 2025-12-05 14:51:52 UTC
Created attachment 190229 [details] [review]
Bug 14962: On Display atomicupdate - DO NOT PUSH
Comment 34 Jake Deery 2025-12-05 14:51:55 UTC
Created attachment 190230 [details] [review]
Bug 14962: On Display svc API changes

This patch updates svc/checkouts to factor in updates to the checkout
process, caused by addition of the effective locations, collection
codes, and branches.
Please see the test files commit for instructions on how to test this
bundle of patches.
Comment 35 Jake Deery 2025-12-05 14:51:59 UTC
Created attachment 190231 [details] [review]
DBIC - DO NOT PUSH
Comment 36 Jake Deery 2025-12-05 14:52:02 UTC
Created attachment 190232 [details] [review]
reword! test suite for bug_14962
Comment 37 Jake Deery 2025-12-05 15:01:20 UTC
Patches above are for people's curiosity / funtime-looking. Some reworking will be needed, and tests are to come. Looking for feedback, please!

Ta,
Jake
Comment 38 David Nind 2025-12-05 22:52:18 UTC
I'd be happy to test, but with so many patches I think this needs a nice consolidated test plan so that mere mortals like myself can test 8-).