Bug ID: 25891
Summary: build_holds_queue can be daemonised
Change sponsored?: ---
Priority: P5 - low
Component: Command-line Utilities
Assignee: [hidden email] Reporter: [hidden email] QA Contact: [hidden email] CC: [hidden email]
We have customers who have come from systems where the holds queue is either
dynamically built at query time or where it's being much more regularly
In their workflows, having to wait for an hour between runs is an annoyance.
With the recent introduction of easy locking mechanisms via the Koha::Script
class we should be able to utilise this functionality to allow the
build_holds_queue job to be demonized such that it runs on a loop.
--- Comment #1 from Katrin Fischer <[hidden email]> ---
Hm, woudl this be optional or that you could still pick the schedule? If you
use the randomized hold targetting it would mean that the holds information
would likely change with every hold added (or whatever triggers the daemon) - I
think that would not be generally wanted.
--- Comment #3 from Katrin Fischer <[hidden email]> ---
Maybe to explain better: hold information = the library picked to get the item
off the shelf. I think the reason it's on a slow schedule by default is that
the idea was to give people time to fetch the items in a multi-library setting.
I can see that it would work well for a single branch library if it showed
immediately. Different use cases to think about!
--- Comment #4 from Sally <[hidden email]> ---
Hi Katrin, I was one of the people who requested this - hopefully this bit of
background might be useful.
We have over 40 sites where books can be transferred to/from. We only use
biblio level holds, we use the Transport Cost Matrix to choose the 'optimal'
library to fill the hold, and the Holds Queue to generate the list of items for
the staff to look for.
As we have so many libraries, a lot of stock, and all of our holds are biblio
level, there can be crossovers, i.e.
The holds queue is generated by Koha at 1pm.
BBB library's holds queue shows a request for item 005 on record QQQ for a
patron at AAA library.
A patron at AAA library coincidentally returns item - 002 - from QQQ record.
002 item on QQQ record is trapped for the hold at AAA library.
Staff at BBB library start working through the holds queue using the
information generated at 1pm.
They locate item 005 on QQQ record and scan it in.
Koha informs them that the item is no longer required.
I realise that when you write it out like this, it's easy to think, "Wow, that
scenario must be fairly rare!" ...but it happens constantly (on a daily basis)
because we use biblio level holds and because we have so many items /
It is a real source of frustration for the staff - if they've been sent to find
60 items and 10 of them are no longer required because they were filled half an
hour earlier, it's a bit galling.
It also affects us because holds queue is one of those jobs which is scheduled
- but if the library is quiet, many staff will load it up and see if they can
fill any, because we put a lot of emphasis on filling and transferring holds as
quickly as possible.
This is a common scenario:
Holds queue - built at 5pm.
Staff do holds queue - it has 50 items on, and they find 25.
Staff change shifts.
It's quiet at 5.45pm so a staff member loads holds queue.
There are still 50 items as it hasn't refreshed.
Staff start to look for items, not realising that half of them have already
We mitigate that by asking the staff to share print outs, and informing them
when it refreshes.
Despite this, it's a source of confusion for the staff, because they don't
understand why the request isn't instantly removed from the holds queue once
it's been filled / been made missing / is no longer required.