Bug 32778 - Auto-unsuspended holds do not trigger realt-ime holds queue update
Summary: Auto-unsuspended holds do not trigger realt-ime holds queue update
Status: RESOLVED DUPLICATE of bug 32565
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-02-01 12:42 UTC by Laura Escamilla
Modified: 2024-05-15 09:59 UTC (History)
9 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 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 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.