https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12556 --- Comment #4 from Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> --- (In reply to Benjamin Rokseth from comment #2)

I notice this bug is rather old, but we actually suffered badly from this, as we have several fully automated branches that are open 24/7 without staff.

They get better with age, like good wine and other stuff. Sorry to hear about your misery. We can completely relate to that :)

Our solution, by any mean not ideal, was to have separated branches for automated selfcheck machines, a SIP translation proxy that fixes the items that are NOT reserved so they can be put directly on the shelf, and finally a cronjob to clean up the branchtransfer mess.

Our self-service libraries are separate branches and strangely I haven't heard of this problem manifesting yet for us, but I know sooner or later someone will notice.

We (Oslo Public Library) would gladly cooperate on this if any good ideas turn up! You could attach the opening hours of the pickup library in the hold notification? Maybe this would help? Tinker a bit with the Letters-module. The C4::Letters::GetPreparedLetter() is very very hairy tho. Also you would need to add the library opening hours somewhere. Easiest thing to do is to make a YAML-config syspref with those opening hours per branch. Super fast GUI-replacement and will get this problem solved in no time. No need for DB or GUI code.

Instead of an email being sent immediately at that point to the patron next in line for the request, the item would have a new circulation status e.g. ‘In SelfService’ this removes the item from the patron’s record but does not trigger the next hold until it is checked-in by a member of the library, at which point the item moves onto the next circulation status that it would have had before going into ‘In SelfService’ (e.g. ‘On hold’ or ‘in transit’ etc.)

However if the limbo-available-state between check-in can be fixed, (this might be more trouble than it's worth) I guess this would make sense.

Maybe this idea is a good solution? Put all SIP2-server checkouts to a Limbo-state Skip catching holds and transfers when put to a 'Limbo'-status? But relinguish ties to the previous borrower. Show in OPAC/Intra the status as Limbo, this is more brittle to program. Shouldn't be too difficult to test and program in. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.