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.
following
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.
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.
Should it be more of a permission or a pref kind of thing?
Maybe a syspref that enables the permission? As we do with circ overrides?
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 😉.
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?
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.
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.
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?
*** This bug has been marked as a duplicate of bug 29346 ***