[Koha-bugs] [Bug 24488] Holds to Pull sometimes shows the wrong 'first patron' details

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24488

--- Comment #95 from Nick Clemens <nick at bywatersolutions.com> ---
(In reply to Katrin Fischer from comment #94)
> (In reply to Jonathan Druart from comment #93)
> > Sorry, the last patch was silly indeed. I hadn't turned on the strict mode.
> > 
> > Your suggestion, Josef, of assuming that the highest priority hold has
> > priority=1 is great actually. I think we never wanted to assume that (in
> > case the data is corrupted?) in this script, but we should go for it IMO,
> > that simplifies the code, the queries, and it makes sense to me!
> 
> I believe in the past we had issues with the priorities not being correct,
> but believe it was fixed (hopefully). Nick or Kyle might be able to tell.
> 
> Wondering what happens with the local holds priority settings - do they
> change the priority in the db or do they check highest priority for local?

I checked in our production sites, there are few cases where the highest
priority is not 1, and they mostly seem to be related to other issues
(suspended holds, holds in the future, missing items) so nothing that should
show on holds to pull.

Local holds don't alter the priority, they get checked first when filling holds
or building the queue, so this report won't catch them, but I think that is
fine as this report isn't branch specific

Other options (for another bug) would be:
1 - List all the holds - just show the first and maybe add a modal to see all
the others
2 - Create a cron like the holds queue, build this page on the backend and
simply display - it adds a delay to new holds showing, but allows us to
calculate the exact holds to be pulled
3 - Add a branch limiter to the report and default to local branches items

-- 
You are receiving this mail because:
You are watching all bug changes.