[Koha-devel] Ponderings on locations

Michael Hafen michael.hafen at washk12.org
Tue Mar 5 18:27:50 CET 2024


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 at 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 at desy.de
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20240305/29cbc86d/attachment.htm>


More information about the Koha-devel mailing list