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.