Auto-unsuspended holds, or future holds, do not trigger the RealTimeHolds queue updates.
An easy fix for this is to add a single forced run of the holds queue to the early morning hours after the auto-unsuspend job runs, to force these onto the list. We should add that to our default cron.daily/koha-common cron definition. And also fix the unsuspend job to tickle the real time hold queue. Just belt and bracers. Cheers, Liz
This is happening more and more often as our patrons get used to setting hold start dates and suspending holds. I'd love to get this fixed ASAP! We discover the hold when another patron brings the item to the desk, and that is very disconcerting for everyone involved.
Hi Sarah! A new cron job option was added on bug 32565 that should address this. *** This bug has been marked as a duplicate of bug 32565 ***
(In reply to Liz Rea from comment #1) > We should add that to our default cron.daily/koha-common cron definition. I agree, bug 32565 implements the new cron options but does not actually add the cron entry to the default koha-common cron definition. I believe the new cron entry needs to be added manually.
(In reply to Pedro Amorim from comment #4) > (In reply to Liz Rea from comment #1) > > We should add that to our default cron.daily/koha-common cron definition. > > I agree, bug 32565 implements the new cron options but does not actually add > the cron entry to the default koha-common cron definition. > I believe the new cron entry needs to be added manually. I think if we add the unallocated param, we also need to make sure that the RealTimeHoldsQueue is activated in new installations by default as they "play together". Should we do that?
(In reply to Katrin Fischer from comment #5) > I think if we add the unallocated param, we also need to make sure that the > RealTimeHoldsQueue is activated in new installations by default as they > "play together". > > Should we do that? That's a good point, I was of the mindset that having the new cron entry added by default would never cause harm, RTHQ or not, but I believe Nick explained why that isn't the case in bug 32565. I like the idea of having RTHQ on by default on new installations but I'm not entirely sure of the possible consequences of this.
(In reply to Pedro Amorim from comment #6) > (In reply to Katrin Fischer from comment #5) > > I think if we add the unallocated param, we also need to make sure that the > > RealTimeHoldsQueue is activated in new installations by default as they > > "play together". > > > > Should we do that? > > That's a good point, I was of the mindset that having the new cron entry > added by default would never cause harm, RTHQ or not, but I believe Nick > explained why that isn't the case in bug 32565. > I like the idea of having RTHQ on by default on new installations but I'm > not entirely sure of the possible consequences of this. Maybe something we should discuss with Nick. I think we either keep the "total rebuild" and RTHQ off or we turn it on and add the --unallocated to the nightly rebuild.