[Koha-bugs] [Bug 12556] SelfCheck machine starts the hold instantly with an email sent out

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12556

--- Comment #4 from Olli-Antti Kivilahti <olli-antti.kivilahti at 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.