Summary: | Add an option for holds queue to only map unassigned requests to items | ||
---|---|---|---|
Product: | Koha | Reporter: | Nick Clemens (kidclamp) <nick> |
Component: | Hold requests | Assignee: | Bugs List <koha-bugs> |
Status: | RESOLVED DUPLICATE | QA Contact: | Testopia <testopia> |
Severity: | enhancement | ||
Priority: | P5 - low | CC: | clemens.tubach, gmcharlt, lisette, michaela.sieber |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34686 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: | ||
Circulation function: |
Description
Nick Clemens (kidclamp)
2023-08-31 15:23:04 UTC
I don't think that the RT holds queue rebuilds the whole table, but that it does rebuilt all entries for one biblionumber, which can also cause issues with the timestamps (a library might use it to print request slips to closed stacks) Nick, are you sure it's completely rebuilt or is this just an issue with the cron? (In reply to Katrin Fischer from comment #1) > I don't think that the RT holds queue rebuilds the whole table, but that it > does rebuilt all entries for one biblionumber, which can also cause issues > with the timestamps (a library might use it to print request slips to closed > stacks) > > Nick, are you sure it's completely rebuilt or is this just an issue with the > cron? You are correct, it is only per biblio that RTHQ rebuilds the queue, but some libraries would like items to remain on the queue for longer Yes, I am adding Michaela as I think if we made the update more clever, that would also resolve the issue they found with the timestamps getting updated (and thus making it not reliable to be used as an indicator for what has been printed already). |