Forgive me if I add to your confusion a bit instead of clearing it up. There are actually three locations in Koha: Permanent location, current location, and shelving location. The first two only matter if you have more than one site; if you only have one site you can set them to the same value and effectively ignore them. These are home branch and holding branch internally. It seems like most of what you are talking about here is the Shelving Location. I'll also mention that Koha can have pseudo patrons also, these can be one of many types. For example I have an Organizational type patron category called 'Library', and I may have a 'On Display', or 'Repair room' patron in that category. This doesn't help with automatically changing the Shelving Location though. There is also an 'after_circ_action' plugin hook. Perhaps there is, or you could have created, a Koha plugin to mangle the Shelving Location based on who an item is checked out to / returned from. On Tue, Mar 5, 2024 at 10:08 AM Wagner, Alexander via Koha-devel < koha-devel@lists.koha-community.org> wrote:
Hi!
While migrating our catalogue to Koha I get quite confused with the location handling. Location for me is "the place where I have to go to fetch the item". So an item could be in the general collection `main reading room`, but I may have a special area there like an exhibition or a new items shelf. And it can be at it's usual location or at some temporary place.
AFAIS Koha items have internally a `location` and a `permanent_location`. (In my still current world they'd be named `temporary location` (876__l) and `location` (aka `852__a`), respectively, so slightly the other way round.)
Now, in item cataloguing the location I get exposed to the editor seems to be a mixture of `permanent_location` and `location`, in the sense that the editor always sets both. Using mappings for `UpdateItemLocationOnCheckin` however, some values are magic. If `CART` and `PROC` get mapped they only change the `location`, while all others change both. (I do understand that the magic value is used by some cron-job.)
However, I wonder if the procedures were not more flexible and easier to understand if "any mapped location" juggles the `location` and leaves the `permanent_location`, while I do get both values in the item editor and the actual place where an item is is defined as `permanet_location` if there is no `location` set. There is already `_PERM_` to access the permanent location in mappings, but with the current logic it's value is gone once a non-magical location enters the game. IMHO one could achieve the same functionality like now by just clearing `location` once an item is back at it's permanent location. (At least this is how our old system does it right now.)
Example:
- We order an item and set it's location to `On Order`. ORD is non-magical. - The item arrives, I check it in, `ORD: PROC` "moves" it to cataloguing. Cataloguing wants to change the permanent location. - After cataloguing it should go to the new items shelf. Check in, `PROC: NEW`.
Everything fine in the OPAC display.
- After a week or so on the new items shelf, check in, `NEW: _PERM_` moves it back to `on order`.
To work around my trouble with the location, I played with a similar juggling for `UpdateNotForLoanStatusOnCheckin`. (Sidenote: it seems that I am required to use numbers for the values to juggle there, e.g. `-1: -3`, while the editor allows for text. If this is a bug I'd add one to bz.) This propagates as expected and from a display perspective it would also be ok.
Unfortunately, the strict `not for loan` doesn't work well for us. We are open 24/7, but not staffed 24/7. IOW whatever hits the shelf can be taken. If someone checks out an item that is in principle not for loan, I'd really like to check it out, just to know who has it ;) I did not yet find a way to soften `not for loan` to something like `2 days and immediately send a recall letter`. (Current procedure.)
Additionally, we check in _all items_ from the CART all the time as we have a lot of patrons that just drop them into the box and they need to be returned to get the RFID into the proper state. (So in our case the cron wouldn't help.)
BTW: what proved pretty flexible in our current system are what I called back then "special patrons". If I check out an item to those the item is not actually checked out, but they manipulate some Marc fields. We used them a lot to set the temporary locations to values like `repair`, `cataloguing`, `on display` or `library desk` (for items ready for the patron to fetch; Koha does this differently). Unlike checking in, where I have to rely on automatic propagation, checking out allows to select what I want to do by means of the cardnumber I get as a second parameter on the SIP-terminal. For configuration I used something like
788 _7 |2 P:(DE-HGF) |a {"j": "available", "l": "Cataloguing"} |i 8767_
which would set `876 7_ |javailable |lCataloguing`, ie the item is available, but in cataloguing. (Our patrons are currently just authority records, so I have full Marc at my disposal.)
-- Kind regards,
Alexander Wagner
Deutsches Elektronen-Synchrotron DESY Library and Documentation
Building 01d Room OG1.444 Notkestr. 85 22607 Hamburg
phone: +49-40-8998-1758 e-mail: alexander.wagner@desy.de _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/
-- Michael Hafen Washington County School District Technology Department Systems Analyst