[Bug 19288] New: Holds placed on a specific item after a next available hold will show varied results
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 Bug ID: 19288 Summary: Holds placed on a specific item after a next available hold will show varied results Change sponsored?: --- Product: Koha Version: 16.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Hold requests Assignee: koha-bugs@lists.koha-community.org Reporter: kelly@bywatersolutions.com QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com, kyle@bywatersolutions.com, nick@bywatersolutions.com When a hold is placed on an item as "next available" and then a hold is placed on same item, but it is placed on a specific copy, Koha will show the specific copy hold on the status screen of the item incorrectly and sometimes give the hold to that specific copy before next available. On 16.11.07 Steps: 1. Place a "next available" hold on an item with only one copy. 2. Place a "specific item" hold this same record. 3. Looking at the holds- they are in the correct order 4. Look at the status of the item in the holdings table you can see that the hold for the "specific copy" is next- not the next available. 5. Check this item in and see which hold gets filled first. 6. Results vary on the process of who gets the hold when checking in this item . Sometimes the specific item will get filled before the hold that was placed as next available even though the "Next available" hold was placed first. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer@bsz-bw.de --- Comment #1 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Could settings like preferring local holds play into that? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 --- Comment #2 from Kelly McElligott <kelly@bywatersolutions.com> --- Katrin, This library that felt the process did not work is a single branch library- so local holds don't really come into play with her process. Kelly -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 --- Comment #3 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I was wondering because you said it's not consistent, if there was another factor. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff Patch complexity|--- |Trivial patch -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 --- Comment #4 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 76099 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=76099&action=edit Bug 19288: Only display holds if next in queue or waiting To test: 1 - Place a title level hold on a biblio for a patron 2 - View the details, the item(s) has no info about holds 3 - Place an item level hold for an item on the same biblio for another patron 4 - View the details page, note the item indicates it is held for the second patron 5 - Apply patch 6 - Refresh details, the hold is not indicated 7 - Set the item specific hold to be priority #1 8 - Refresh details, the hold should now be indicated 9 - Confirm the hold 10 - Refresh details, the hold should show as waiting -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 --- Comment #5 from Nick Clemens <nick@bywatersolutions.com> --- This patch will only show the hold if it is next in the priority list, however, localholds priority and other settings may mean the hold triggered at checkin is not the one listed. Would it be reasonable to only show "there is a hold on this item" unless the hold is waiting? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 --- Comment #6 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 76100 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=76100&action=edit Bug 19288: [Alternate] Only show existence of item level hold unless waiting To test: 1 - Please a biblio level hold for one patron, and an item level hold for another on same record 2 - Note that you patron name for item lvel hold 3 - Apply patch 4 - You should now see 'There is a hold on this item' with no patron detail 5 - Confirm hold, patron detail should be visible -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |nick@bywatersolutions.com |ity.org | -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 Michal Denar <black23@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |black23@gmail.com --- Comment #7 from Michal Denar <black23@gmail.com> --- Please rebase on master. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 --- Comment #8 from Nick Clemens <nick@bywatersolutions.com> --- (In reply to Michal Denar from comment #7)
Please rebase on master.
Either patch seems to apply, you should not apply both, they are alternate options I suggest the second patch, but want opinions -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 Chris Slone <cslone@camdencountylibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cslone@camdencountylibrary. | |org -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 Liz Rea <wizzyrea@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 Liz Rea <wizzyrea@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #76099|0 |1 is obsolete| | Attachment #76100|0 |1 is obsolete| | --- Comment #9 from Liz Rea <wizzyrea@gmail.com> --- Created attachment 89059 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=89059&action=edit Bug 19288: [Alternate] Only show existence of item level hold unless waiting To test: 1 - Please a biblio level hold for one patron, and an item level hold for another on same record 2 - Note that you patron name for item lvel hold 3 - Apply patch 4 - You should now see 'There is a hold on this item' with no patron detail 5 - Confirm hold, patron detail should be visible Signed-off-by: Liz Rea <wizzyrea@gmail.com> I like the 2nd approach better. :) -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|16.11 |master -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |In Discussion --- Comment #10 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I am not sure here if less information is better. Maybe the original message should just be phrased a bit better? We switch from: Item-level hold (placed 05/11/2019) for delivery at Centerville. Hold for: katrin koha (42) To: There is a hold on this item I am also not sure how this related to the initial bug report, where Kelly reported that sometimes the item level hold would be filled first, even if not first in the queue. Can you explain? While the first message is very 'talkative', maybe we can find some middle ground? Something like: Item-level hold for .... (priority x) (similar to how we display the priority in the OPAC) And I would leave out the hold placed and pickup location. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |oleonard@myacpl.org -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Signed Off --- Comment #11 from Nick Clemens <nick@bywatersolutions.com> --- (In reply to Katrin Fischer from comment #10)
I am not sure here if less information is better. Maybe the original message should just be phrased a bit better?
We switch from:
Item-level hold (placed 05/11/2019) for delivery at Centerville. Hold for: katrin koha (42)
To:
There is a hold on this item
I am also not sure how this related to the initial bug report, where Kelly reported that sometimes the item level hold would be filled first, even if not first in the queue. Can you explain?
While the first message is very 'talkative', maybe we can find some middle ground? Something like:
Item-level hold for .... (priority x) (similar to how we display the priority in the OPAC)
And I would leave out the hold placed and pickup location.
As I understand the main issue, the problem is that Koha shows one hold on the details page, and triggers another at checkin. Different factors can affect which hold will be triggered at checkin, and we don't want to do too many calculations to show the item details, so we are getting a simple 'what's in the queue' and showing the wrong name. Trying to show the correct name is the issue. Until the hold is actually waiting it can fluctuate. I think this solution gives the library the info they need "Check this item in to trigger a hold" without adding info that may be wrong -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 --- Comment #12 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Can you explain why the displayed patron would not be the one receiving the next item? I have thought about it, but fail to come up with a use case. And if it's not something that depends on environment (current library location or something) we should be able to fix it. Our libraries are mostly single branch and I think for them this works well and they would not like it being removed for some less informative text. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |In Discussion -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 --- Comment #13 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- We should not make such a change without fully understanding the why and how here. That's why I pick 'in discussion'. If we end up doing it, I want to be able to explain to the libraries why. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 --- Comment #14 from Nick Clemens <nick@bywatersolutions.com> --- (In reply to Katrin Fischer from comment #13)
We should not make such a change without fully understanding the why and how here. That's why I pick 'in discussion'. If we end up doing it, I want to be able to explain to the libraries why.
Imagine Patron A has a 'next available' hold and Patron B has an item level hold on Item A To find the holds on an item we call Koha::Item::current_holds - this will returnholds on the specific item, it will never find 'next available' holds because they are not on a specific item - We will display Patron B At checkin we actually check the holds, and we check hold_fill_targets at some level. The effect being that if you have not run the holds queue the item will fill the higher priority hold for Patron A, however, if you have built the holds queue it could do a few things: If there are multiple items available then Patron A may get assigned Item B for the queue and Patron B will get Item A - for this scenario Item A will trigger for patron B If there is only one available item then Patron A will be assigned Item A and Item A will trigger Patron A This scenario seems reasonable, the holds queue is going to try and fill the holds so that both patrons can get the item they want if it can. For display though we would need to check the DB for both hold_fill_targets and specific holds. I don't think this information of who gets the hold is so important on details, since we will resolve it at checkout, I think simply letting the librarian know this item is held should suffice. I will ask around internally for more opinions -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrew@bywatersolutions.com --- Comment #15 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- First thought: the inconsistent capturing behavior is the more pressing issue here. Let's not lose that while addressing the wording on the item details. Second: I like changing the item details message to just "there is a hold on this item." The greater context of who the hold is for, where it will be picked up, and what priority it's at is all just a click away on the Holds tab, where it is presented in a clearer, more contextualized fashion. Making the note in item details try to give all that information is trying to shove a lot of detail into a small box, which sets us up for misunderstandings when folks don't read that information carefully. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=20948 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Signed Off -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |RESOLVED CC| |m.de.rooy@rijksmuseum.nl Resolution|--- |DUPLICATE --- Comment #16 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Bug 20948 has hit PQA in favor of this one, sorry ;) Please reopen and explain if this cannot be closed. *** This bug has been marked as a duplicate of bug 20948 *** -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|DUPLICATE |--- Status|RESOLVED |REOPENED -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #89059|0 |1 is obsolete| | --- Comment #17 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 95898 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=95898&action=edit Bug 19288: Don't show patron info for item level holds on details.pl unless hold is waiting This persists after bug 20948 - we can still display patron information even if this patron is not the one who will receive the item upon checkin. The holds tab can give an overview of holds and information - I think on the details page the only info we need is whether there might be a item level hold, not who it is for To test: 1 - Place an item level hold for delivery at a branch not matching home branch of item 2 - Place a record level hold for delivery at homebranch of item placed on hold above 3 - Enable LocalHoldsPriority with 'pickup library' matches the item's 'home library' 4 - View the details for the page, it says the item has a hold for the patron with an item level hold 5 - Check in the item, the hold triggered is for the next available patron, ignore the hold 6 - Apply patch 7 - Check details page, 'There is an item-level hold (priority=1)' with no patron info 8 - Check in, next available hold is still the one triggered -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 --- Comment #18 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Nick, does it depend on 20948 now ? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |20948 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20948 [Bug 20948] Item-level hold info displayed regardless its priority (detail.pl) -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 --- Comment #19 from Nick Clemens <nick@bywatersolutions.com> --- (In reply to Marcel de Rooy from comment #18)
Nick, does it depend on 20948 now ?
Yes :-) -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 --- Comment #20 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- FAIL koha-tmpl/intranet-tmpl/prog/en/modules/catalogue/detail.tt FAIL filters missing_filter at line 367 ( There is an item level hold on this item (priority = [% hold.priority %]).) -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #95898|0 |1 is obsolete| | --- Comment #21 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 100328 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=100328&action=edit Bug 19288: Don't show patron info for item level holds on details.pl unless hold is waiting This persists after bug 20948 - we can still display patron information even if this patron is not the one who will receive the item upon checkin. The holds tab can give an overview of holds and information - I think on the details page the only info we need is whether there might be a item level hold, not who it is for To test: 1 - Place an item level hold for delivery at a branch not matching home branch of item 2 - Place a record level hold for delivery at homebranch of item placed on hold above 3 - Enable LocalHoldsPriority with 'pickup library' matches the item's 'home library' 4 - View the details for the page, it says the item has a hold for the patron with an item level hold 5 - Check in the item, the hold triggered is for the next available patron, ignore the hold 6 - Apply patch 7 - Check details page, 'There is an item-level hold (priority=1)' with no patron info 8 - Check in, next available hold is still the one triggered Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.renvoize@ptfs-europe | |.com Status|Needs Signoff |Signed Off --- Comment #22 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Had to rebase this to apply it.. works as expected.. Signing off -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 --- Comment #23 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Signed off as it does what's described.. would be interested in an update from Andrew or Kelly regarding the requirements however prior to a QA run. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #100328|0 |1 is obsolete| | --- Comment #24 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- Created attachment 100632 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=100632&action=edit Bug 19288: Don't show patron info for item level holds on details.pl unless hold is waiting This persists after bug 20948 - we can still display patron information even if this patron is not the one who will receive the item upon checkin. The holds tab can give an overview of holds and information - I think on the details page the only info we need is whether there might be a item level hold, not who it is for To test: 1 - Place an item level hold for delivery at a branch not matching home branch of item 2 - Place a record level hold for delivery at homebranch of item placed on hold above 3 - Enable LocalHoldsPriority with 'pickup library' matches the item's 'home library' 4 - View the details for the page, it says the item has a hold for the patron with an item level hold 5 - Check in the item, the hold triggered is for the next available patron, ignore the hold 6 - Apply patch 7 - Check details page, 'There is an item-level hold (priority=1)' with no patron info 8 - Check in, next available hold is still the one triggered Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #100632|0 |1 is obsolete| | --- Comment #25 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- Created attachment 100633 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=100633&action=edit Bug 19288: Don't show patron info for item level holds on details.pl unless hold is waiting This persists after bug 20948 - we can still display patron information even if this patron is not the one who will receive the item upon checkin. The holds tab can give an overview of holds and information - I think on the details page the only info we need is whether there might be a item level hold, not who it is for To test: 1 - Place an item level hold for delivery at a branch not matching home branch of item 2 - Place a record level hold for delivery at homebranch of item placed on hold above 3 - Enable LocalHoldsPriority with 'pickup library' matches the item's 'home library' 4 - View the details for the page, it says the item has a hold for the patron with an item level hold 5 - Check in the item, the hold triggered is for the next available patron, ignore the hold 6 - Apply patch 7 - Check details page, 'There is an item-level hold (priority=1)' with no patron info 8 - Check in, next available hold is still the one triggered Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Amended patch: fix indentation -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to master Version(s)| |20.05.00 released in| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 --- Comment #26 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Nice work everyone! Pushed to master for 20.05 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 Joy Nelson <joy@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |joy@bywatersolutions.com Version(s)|20.05.00 |20.05.00, 19.11.05 released in| | Status|Pushed to master |Pushed to stable --- Comment #27 from Joy Nelson <joy@bywatersolutions.com> --- Backported to 19.11.x branch for 19.11.05 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 Lucas Gass <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)|20.05.00, 19.11.05 |20.05.00, 19.11.05, released in| |19.05.10 CC| |lucas@bywatersolutions.com Status|Pushed to stable |Pushed to oldstable --- Comment #28 from Lucas Gass <lucas@bywatersolutions.com> --- backported to 19.05.x for 19.05.10 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 Hayley Mapley <hayleymapley@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hayleymapley@catalyst.net.n | |z --- Comment #29 from Hayley Mapley <hayleymapley@catalyst.net.nz> --- Minor patch will not be backported to 18.11.1x series -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=24301 -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org