Hello Emily! > Many of the things you're trying to do can be done in Koha through some other > mechanism.
:) >> E.g. if it has been requested and is prepared for some patron >> another one will not find it in the shelves, so IMHO it is a good >> idea to show in OPAC that it is in a different location. > > In Koha we would do this by placing a hold on the item for that patron, and > then > check the item in and confirm the hold, right? IOW the _status_ `on hold` describes that the item _is already_ on the shelf of items prepared for our patrons. (What we called `Library Desk HH`). > then Koha will display it as "On hold" in the OPAC and > "Waiting hold for such-and-such patron" on the Staff Intranet. So in Koha Current library: DESY Hamburg Library Location: Main Status: On hold is the same thing as Library: DESY Hamburg Library Location: Library Desk HH I'll just correct my thinking here and adopt Kohas view. :) >> Unfortunately, the strict `not for loan` doesn't work well for us. We [...] >> immediately send a recall letter`. (Current procedure.) > > One way you could do this would be to define a NOTFORLOAN item type, and then > edit the Circulation and Fines Rules to give that item type a loan period of 2 > days with no renewals. This is what I actually did already together with changing all `not for loan` loan periods we have right now. I just mentioned the not for loan feature as it entered this "where is the book right now" game somewhat unexpectedly (for me). What got me confused quite a bit was that there is - `UpdateItemLocationOnCheckin`: Ok, this is plausible. If I check in an item it is in some other place. Especially, if I explicitly treat CART as a location, which is sensible. (That we didn't till now is more a failure in our current system, that I will not fix any more.) - `UpdateNotForLoanStatusOnCheckin`: This however, I found completely unrelated, cause the loan period is independent from the items location. So I played with both of them and noticed that they both also trigger displays in OPAC. Both basically use the same kind of translation tables (if status is x change it to y once an item is checked in) while I noticed that only the `UpdateNotForLoanStatusOnCheckin` managed all stages as described in the translation tables while `UpdateItemLocationOnCheckin` behaved "stange" at first sight as I got this incorrect permanent location set. I think, I now got why the `not for loan`-status entered the game, though it is still a bit strange to me and as mentioned it does not work as a work around for exhibtions, new itmes etc. (But loan periods and not for loan handling in Koha is completely different to our current system anyway, so I'll just have to adopt to Kohas view.) > If you want Koha to automatically send a recall letter > for those that is different than the standard due/overdue notice, that would > take a bit of doing when adjusting the notice template, but off the top of my > head I believe it would be possible. I think if I have a short loan period they'd trigger the first recall, so this should be fine. But I'll double check. (I'll have to dive a bit more into the recall procedures, as I fear not all of our patrons return their items after the 3rd notice, but that's another issue.) > That being said, it certainly would be nice to have more flexibility in > defining > temporary locations for items (such as displays or mending) - there is (at > least one) bug for that in Bugzilla if you want to follow and/or comment: > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14962 Somehow I knew that my thinking isn't too strange. Thanks for the poiner! I think 14962 is indeed pretty spot on. One thing I do not understand is, why CART and PROC have to be special in the first place. If the mapping table just works on `location` and leaves `permanent_location` alone (like it does for PROC and CART) I think things work as expected once in some final steps I map `<something>: _PERM_`. IOW I do not understand why checkin touches a permanent location that was set during cataloguing as some conscious decision: we shelve this item in the special reading room etc. > Our library system is currently in the process of working with ByWater to > sponsor/co-sponsor a feature like that. As mentioned, unless I overlook something deep in some other areas not too much feature may be required, but more removal of magic. 14962 describes yet another location, but I think this is not required as `items.location` is basically the described temp-location. But I am to new to Koha to understand all implications. > Finally, I just want to clarify that Shelving Location does indeed consist of > both a "location" and "permanent location" (separate from homebranch and > holdingbranch), though that's not necessarily obvious depending on where > you're > looking, and you're right that the distinction mostly exists for the benefit > of > the "magic" values of CART and PROC. So, if all automagic juggling works on `items.location` and the rules somehow know when to clear `items.location`... > I point this out partly because it can be > a stumbling block in custom SQL reports...I learned this the hard way when an [...] > in large numbers of books in the process! I see your point. Noted down. Indeed, I stumbled there as well once I inspected the items-table. -- 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.wag...@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/
