Bug 26003 - Could the holds queue be live rather than built via cron
Summary: Could the holds queue be live rather than built via cron
Status: RESOLVED DUPLICATE of bug 29346
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-07-17 12:13 UTC by Martin Renvoize
Modified: 2022-04-01 07:39 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Renvoize 2020-07-17 12:13:53 UTC
I get the feeling that the functionality of the holds queue could be achieved via triggers after various actions rather than require a regular full rebuild via a cron job.

I'm thinking the action of placing a hold, the action of checking in items and checking out items... these are the main things that can affect the holds queue data and such actions should be able to trigger a small calculation to update the holds queue for the related item, branch etc.
Comment 1 Andrew Fuerste-Henry 2020-07-17 12:39:52 UTC
following
Comment 2 Katrin Fischer 2020-07-18 14:41:43 UTC
I think it's a great idea.

The only downside I can think of is when libraries regularly print the list - they might like to have a way to just print the "new entries since" or similar. But it would be interesting to know how this list is actually used in the libraries.

I think it would also be great if there was an easy way to say "we can't deliver, try the next library' - not only by setting things to lost or similar, because I imagine there could be multiple reasons for not being able to deliver apart from not finding an item.
Comment 3 Andrew Fuerste-Henry 2020-07-20 13:03:28 UTC
I've worked with libraries who want a button for "we can't deliver, try the next library," so I agree that it'd be a good feature. But I've also worked with libraries where that button would become a source of tension, with librarians opting not to fill holds that their consortial agreements say they should fill. So I'd like to see some mechanism to log that opt-out and/or the ability to disable the opt-out ability altogether.
Comment 4 Katrin Fischer 2020-07-20 20:29:53 UTC
Should it be more of a permission or a pref kind of thing?
Comment 5 Andrew Fuerste-Henry 2020-07-20 20:43:58 UTC
Maybe a syspref that enables the permission? As we do with circ overrides?
Comment 6 Martin Renvoize 2020-07-21 05:26:25 UTC
Just a heads up that I don't actually have any funding/support for this here yet, just a few customers and trainers who brought the idea to my attention.. and yes, that is in part due to the request for a "mark lost" or/and "can't fulfill" button on the report.

I'd love to work on this and have various ideas of how to achieve it but I won't have the opportunity to get going on it, in the short term at least, unless someone wants to help pay the bills 😉.
Comment 7 Christopher Brannon 2020-10-02 15:30:01 UTC
I am trying to understand how the queue currently exists, and maybe this is a good place to chime in.

I am seeing some inefficiency in the way the queue behaves, and the frequency at which we need updates.  We update the queue every 15 minutes.  I'm trying to understand why we need to update a queue.  Apparently the table the queue lives in is not live?

I say this, because we can run the queue several times in a row, and I watch each load of the queue go from 22 items to 0, to 4, to 17, to 21, and back to 22, and very little has changed.  Mostly the same items.  So, it looks like this table is wiped out and built from scratch.  That in itself makes me ask, why?
Comment 8 Martin Renvoize 2020-10-03 06:43:35 UTC
That is indeed exactly how it works currently Christopher.  The queue rebuilds via a cronjob, with the very first step in the script being a truncation of the table.  Assuming you have not changed any weighting settings and items have not moved around then the exact same queue will result once the script has run its course.

My intention here was to use the same weighting logic as the script uses but trigger that in all locations where item changes can take place.  This work isn't funded though, so I'm not sure when I'll have time to actually work on it.
Comment 9 David Cook 2020-10-20 00:11:35 UTC
Sounds like something that would be nice to process asynchronously in the background. 

Certainly could build a follow-up to Bug 22417 for that I think.
Comment 10 Christopher Brannon 2021-01-29 15:34:09 UTC
What if the queue were built in the background without touching the active queue, then that data replaces the active info when it is finished building.  More of an instant refresh than a refresh while gathering?
Comment 11 Martin Renvoize 2022-04-01 07:39:17 UTC

*** This bug has been marked as a duplicate of bug 29346 ***