Bug 32778

Summary: Auto-unsuspended holds do not trigger realt-ime holds queue update
Product: Koha Reporter: Laura Escamilla <Laura.escamilla>
Component: Hold requestsAssignee: Bugs List <koha-bugs>
Status: RESOLVED DUPLICATE QA Contact: Testopia <testopia>
Severity: normal    
Priority: P5 - low CC: bugzilla, emily.lamancusa, gmcharlt, lisette, nick, pedro.amorim, sally.healey, sbcornell, wizzyrea
Version: Main   
Hardware: All   
OS: All   
GIT URL: Change sponsored?: ---
Patch complexity: --- Documentation contact:
Documentation submission: Text to go in the release notes:
Version(s) released in:
Circulation function:

Description Laura Escamilla 2023-02-01 12:42:34 UTC
Auto-unsuspended holds, or future holds, do not trigger the RealTimeHolds queue updates.
Comment 1 Liz Rea 2024-02-27 14:51:06 UTC
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
Comment 2 Sarah Cornell 2024-05-14 17:24:29 UTC
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.
Comment 3 Emily Lamancusa (emlam) 2024-05-14 19:07:24 UTC
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 ***
Comment 4 Pedro Amorim 2024-05-15 08:21:08 UTC
(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.
Comment 5 Katrin Fischer 2024-05-15 09:03:38 UTC
(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?
Comment 6 Pedro Amorim 2024-05-15 09:18:39 UTC
(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.
Comment 7 Katrin Fischer 2024-05-15 09:59:37 UTC
(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.