Summary: | Holds with start date not appearing in holds queue | ||
---|---|---|---|
Product: | Koha | Reporter: | Sara Brown <sbrown> |
Component: | Hold requests | Assignee: | Bugs List <koha-bugs> |
Status: | RESOLVED DUPLICATE | QA Contact: | Testopia <testopia> |
Severity: | enhancement | ||
Priority: | P5 - low | CC: | emily.lamancusa, gmcharlt |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32565 | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: |
Description
Sara Brown
2024-05-08 14:14:45 UTC
Hi Sara, can you explain the use case? For me this behavior sounds correct as I understand a hold is not "active" until its start date. I'm sorry; I didn't explain it well originally. On the start date, the hold still isn't appearing in the queue. OK, that makes sense. I think there is a bug that might help with that too, but I haven't tested: Bug 32565 - Holds placed when all libraries are closed do not get added to holds queue if HoldsQueueSkipClosed and RealTimeHoldsQueue are enabled The problem is that at the time the hold is placed it's rightfully not added to the queue by RTHQ. But then later it needs the cron to show up. This new switch only looks for "unallocated" holds (not yet in the holds queue) to add them. Ah, that makes sense. And I hit enter on that comment too early: The library's original use case was a staff member placing holds with start dates for an upcoming storytime. They placed the holds about 2 weeks ahead of actually needing the items but found that when the start date came, the holds were only visible on holds to pull (which they don't typically use). |