[Bug 26003] New: Could the holds queue be live rather than built via cron
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26003 Bug ID: 26003 Summary: Could the holds queue be live rather than built via cron Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs@lists.koha-community.org Reporter: martin.renvoize@ptfs-europe.com QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com 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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26003 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrew@bywatersolutions.com --- Comment #1 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- following -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26003 --- Comment #2 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26003 --- Comment #3 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26003 --- Comment #4 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Should it be more of a permission or a pref kind of thing? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26003 --- Comment #5 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Maybe a syspref that enables the permission? As we do with circ overrides? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26003 --- Comment #6 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- 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 😉. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26003 Christopher Brannon <cbrannon@cdalibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cbrannon@cdalibrary.org --- Comment #7 from Christopher Brannon <cbrannon@cdalibrary.org> --- 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? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26003 --- Comment #8 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- 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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26003 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=25891 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26003 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #9 from David Cook <dcook@prosentient.com.au> --- 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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26003 --- Comment #10 from Christopher Brannon <cbrannon@cdalibrary.org> --- 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? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26003 Phil Ringnalda <phil@chetcolibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |phil@chetcolibrary.org -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26003 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #11 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- *** This bug has been marked as a duplicate of bug 29346 *** -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org