https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12556
--- Comment #4 from Olli-Antti Kivilahti <[email protected]> --- (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. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
