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
Doesn't this already exist with the "location" field? If you're losing the permanent location, it could be that there's a bug...
(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
(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.
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.
(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)
Maybe this could work like the course reserves? The former location is stored separate from the item data until the item is moved back
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:
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.
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.
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.
Is this similar/same as bug 31168?
(In reply to Katrin Fischer from comment #11) > Is this similar/same as bug 31168? Seems like a duplicate to me.
*** Bug 31168 has been marked as a duplicate of this bug. ***
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.
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.
*** Bug 30910 has been marked as a duplicate of this bug. ***
(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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Created attachment 190229 [details] [review] Bug 14962: On Display atomicupdate - DO NOT PUSH
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.
Created attachment 190231 [details] [review] DBIC - DO NOT PUSH
Created attachment 190232 [details] [review] reword! test suite for bug_14962
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
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-).