[Bug 34032] New: Holds expirationdate left blank if waiting status is reverted
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032 Bug ID: 34032 Summary: Holds expirationdate left blank if waiting status is reverted Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs@lists.koha-community.org Reporter: emmi.takkinen@koha-suomi.fi QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com Pretty much what summary says. To reproduce: 1) Make sure you have DefaultHoldExpirationdate syspref enabled. 2) Find hold with status "Waiting". 3) Revert waiting status. => Note that hold has no expiration date set. -- 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=34032 Emmi Takkinen <emmi.takkinen@koha-suomi.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |emmi.takkinen@koha-suomi.fi |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=34032 Emmi Takkinen <emmi.takkinen@koha-suomi.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032 --- Comment #1 from Emmi Takkinen <emmi.takkinen@koha-suomi.fi> --- Created attachment 152516 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=152516&action=edit Bug 34032: Set new expirationdate if waiting status is reverted When one reverts holds waiting status holds expiration date is not set even if DefaultHoldExpirationdate syspref is enabled. This patch adds new param hold_reverted to be used when RevertWaitingStatus is used to determine if expiration date should be set again. To test: 1) Make sure you have DefaultHoldExpirationdate syspref enabled. 2) Find hold with status "Waiting". 3) Revert waiting status. => Note that hold has no expiration date set. 4) Apply this patch. 5) Repeat steps 2 and 3. => Expiration date should now be set based on reserve date. Also prove t/db_dependent/Hold.t. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032 Emmi Takkinen <emmi.takkinen@koha-suomi.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032 Sam Lau <samalau@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=34032 Sam Lau <samalau@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #152516|0 |1 is obsolete| | --- Comment #2 from Sam Lau <samalau@gmail.com> --- Created attachment 152535 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=152535&action=edit Bug 34032: Set new expirationdate if waiting status is reverted When one reverts holds waiting status holds expiration date is not set even if DefaultHoldExpirationdate syspref is enabled. This patch adds new param hold_reverted to be used when RevertWaitingStatus is used to determine if expiration date should be set again. To test: 1) Make sure you have DefaultHoldExpirationdate syspref enabled. 2) Find hold with status "Waiting". 3) Revert waiting status. => Note that hold has no expiration date set. 4) Apply this patch. 5) Repeat steps 2 and 3. => Expiration date should now be set based on reserve date. Also prove t/db_dependent/Hold.t. Signed-off-by: Sam Lau <samalau@gmail.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.de.rooy@rijksmuseum.nl --- Comment #3 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Wont complain about WARN C4/Reserves.pm WARN tidiness The file is less tidy than before (bad/messy lines before: 470, now: 471) WARN Koha/Hold.pm WARN tidiness The file is less tidy than before (bad/messy lines before: 126, now: 129) WARN t/db_dependent/Hold.t WARN tidiness The file is less tidy than before (bad/messy lines before: 82, now: 89) -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |m.de.rooy@rijksmuseum.nl |y.org | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA --- Comment #4 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Did not finish this one completely now, but feel somehow that it needs more attention still (qa intuition). Hmm. Reserves still contains: expirationdate => $hold->patron_expiration_date, Are we not respecting that one? my %updated_columns = $self->_result->get_dirty_columns; return $self->SUPER::store unless %updated_columns; This may be obvious. But should we add $hold_reverted here? Or just trust that we have dirty columns coming from RevertWaitingStatus? + ( C4::Context->preference('DefaultHoldExpirationdate') + && ! exists $updated_columns{expirationdate} ) + || ( C4::Context->preference('DefaultHoldExpirationdate') + && exists $updated_columns{expirationdate} + && $hold_reverted ) Still breaking my head here. Could you please clarify in meantime a bit? Thx Status change for feedback. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032 --- Comment #5 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- $hold->set( { priority => 1, found => undef, waitingdate => undef, expirationdate => $hold->patron_expiration_date, itemnumber => $hold->item_level_hold ? $hold->itemnumber : undef, } )->store({ hold_reverted => 1 }); Currently, only this case triggers part of the condition (that could be simplified to reduce repetition) that leads to calling: $self->_set_default_expirationdate; (Unless both dates are still the same..) If they are not, why not respect patron_expiration_date? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032 --- Comment #6 from Emmi Takkinen <emmi.takkinen@koha-suomi.fi> --- Since it has been 4+ months since I worked on this, I'm utterly confused what I have been thinking while doing this. Looking into this again. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032 --- Comment #7 from Emmi Takkinen <emmi.takkinen@koha-suomi.fi> --- (In reply to Marcel de Rooy from comment #4)
Did not finish this one completely now, but feel somehow that it needs more attention still (qa intuition). Hmm.
Reserves still contains: expirationdate => $hold->patron_expiration_date, Are we not respecting that one? If hold is not in storage, then we still use patron_expiration_date. It isn't used even currently when we update hold.
my %updated_columns = $self->_result->get_dirty_columns; return $self->SUPER::store unless %updated_columns; This may be obvious. But should we add $hold_reverted here? Or just trust that we have dirty columns coming from RevertWaitingStatus?
It is probably save to assume that we receive dirty columns here, since reverting waiting status changes holds priority as 1. And by my logic that happens every time we revert.
+ ( C4::Context->preference('DefaultHoldExpirationdate') + && ! exists $updated_columns{expirationdate} ) + || ( C4::Context->preference('DefaultHoldExpirationdate') + && exists $updated_columns{expirationdate} + && $hold_reverted ) Still breaking my head here. Gosh, perltidy turns that block into a mess. But this is unnecessarily complex and a I have no idea what I was thinking when writing this. We can probably achieve same result with this:
( C4::Context->preference('DefaultHoldExpirationdate') && ( ! exists $updated_columns{expirationdate} || $hold_reverted ) )
-- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032 --- Comment #8 from Emmi Takkinen <emmi.takkinen@koha-suomi.fi> --- (In reply to Marcel de Rooy from comment #5)
$hold->set( { priority => 1, found => undef, waitingdate => undef, expirationdate => $hold->patron_expiration_date, itemnumber => $hold->item_level_hold ? $hold->itemnumber : undef, } )->store({ hold_reverted => 1 });
Currently, only this case triggers part of the condition (that could be simplified to reduce repetition) that leads to calling: $self->_set_default_expirationdate; (Unless both dates are still the same..)
If they are not, why not respect patron_expiration_date?
Because I just realized there is a column called patron_expiration_date. Somehow this has totally slipped from my attention. You're right, if patron_expiration_date exists we should respect it, not generate new one. However, what should we do if patron_expiration_date is in past? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032 --- Comment #9 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Emmi Takkinen from comment #8)
(In reply to Marcel de Rooy from comment #5)
$hold->set( { priority => 1, found => undef, waitingdate => undef, expirationdate => $hold->patron_expiration_date, itemnumber => $hold->item_level_hold ? $hold->itemnumber : undef, } )->store({ hold_reverted => 1 });
Currently, only this case triggers part of the condition (that could be simplified to reduce repetition) that leads to calling: $self->_set_default_expirationdate; (Unless both dates are still the same..)
If they are not, why not respect patron_expiration_date?
Because I just realized there is a column called patron_expiration_date. Somehow this has totally slipped from my attention. You're right, if patron_expiration_date exists we should respect it, not generate new one. However, what should we do if patron_expiration_date is in past?
It's a really good question. My thought would be to use the existing date anyway, even if in the past. Some libraries might not auto-cancel those and if they auto-cancel that will be run nightly, so there is still a moment to adjust. Maybe we could do an alert or other visual hint? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032 --- Comment #10 from Emmi Takkinen <emmi.takkinen@koha-suomi.fi> --- (In reply to Katrin Fischer from comment #9)
(In reply to Emmi Takkinen from comment #8)
(In reply to Marcel de Rooy from comment #5)
$hold->set( { priority => 1, found => undef, waitingdate => undef, expirationdate => $hold->patron_expiration_date, itemnumber => $hold->item_level_hold ? $hold->itemnumber : undef, } )->store({ hold_reverted => 1 });
Currently, only this case triggers part of the condition (that could be simplified to reduce repetition) that leads to calling: $self->_set_default_expirationdate; (Unless both dates are still the same..)
If they are not, why not respect patron_expiration_date?
Because I just realized there is a column called patron_expiration_date. Somehow this has totally slipped from my attention. You're right, if patron_expiration_date exists we should respect it, not generate new one. However, what should we do if patron_expiration_date is in past?
It's a really good question. My thought would be to use the existing date anyway, even if in the past. Some libraries might not auto-cancel those and if they auto-cancel that will be run nightly, so there is still a moment to adjust. Maybe we could do an alert or other visual hint?
Hmm, maybe displaying field as red would be enough? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032 --- Comment #11 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Sounds good to me. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032 --- Comment #12 from Emmi Takkinen <emmi.takkinen@koha-suomi.fi> --- Created attachment 158516 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=158516&action=edit Bug 34032: Use reserves.patron_expiration_date if set If reserves.patron_expiration_date is set use it as holds expiration date when waiting status is reverted. To test: 1. Apply this patch. 2. Add hold for patron A and set expiration date manually. 3. Check in item on hold for patron A and confirm hold was set as waiting. 4. Revert holds waiting status. => Hold should still have expiration date you set manually in step 2. 5. Check that you have DefaultHoldExpirationdate and other DefaultHold sysprefs set. 6. Add hold for patron B, but this time do not set expiration date. 7. Check in item on hold for patron B, revert waiting status. => Hold should now have expiration date set based on DefaultHold sysprefs. Also prove t/db_dependent/Hold.t. Sponsored-by: Koha-Suomi Oy -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032 --- Comment #13 from Emmi Takkinen <emmi.takkinen@koha-suomi.fi> --- We don't probably have to do anything to past dates, since they aren't displayed at all. If I set reserves.expirationdate in past (or current date) through database, expiration date field is blank. Is this intentional? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032 --- Comment #14 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Emmi Takkinen from comment #13)
We don't probably have to do anything to past dates, since they aren't displayed at all. If I set reserves.expirationdate in past (or current date) through database, expiration date field is blank. Is this intentional?
Hm, I have been wondering what we show in the GUI but didn't check. It might all be a bit 'history' there. In the past there was only one field in the database used for both the "don't need after x" and "pick-up before". That lead to a couple of issues. Later we divided the fields in the database (yay!), but maybe we don't show both in the GUI? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032 --- Comment #15 from Emmi Takkinen <emmi.takkinen@koha-suomi.fi> --- (In reply to Katrin Fischer from comment #14)
(In reply to Emmi Takkinen from comment #13)
We don't probably have to do anything to past dates, since they aren't displayed at all. If I set reserves.expirationdate in past (or current date) through database, expiration date field is blank. Is this intentional?
Hm, I have been wondering what we show in the GUI but didn't check.
It might all be a bit 'history' there. In the past there was only one field in the database used for both the "don't need after x" and "pick-up before". That lead to a couple of issues.
Later we divided the fields in the database (yay!), but maybe we don't show both in the GUI?
Technically we don't show them both, we show value in reserves.expirationdate. But if reserves.patron_expiration_date is filled, it is copied to reserves.expirationdate (not only with these patches but by default). But this doesn't seem to be the problem here. In GUI it seems that expiration field doesn't display date in past, including if value is current date. They are in database however. There's probably some sort of jQuery (flatpicker maybe) affecting this. I was wondering should we should also show dates in past and display them with visual hind or does the field behave this way on purpose? I was also wondering if we "fix" this, should it be done in another bug? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=35306 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032 --- Comment #16 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Hi Emmi, I just came across bug 35306 that seems to be related and maybe explains what we have been wondering about here. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032 --- Comment #17 from Emmi Takkinen <emmi.takkinen@koha-suomi.fi> --- (In reply to Katrin Fischer from comment #16)
Hi Emmi, I just came across bug 35306 that seems to be related and maybe explains what we have been wondering about here.
So it seems and expiration date is now displayed as plain text. However with these patches expiration date changes. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032 Emmi Takkinen <emmi.takkinen@koha-suomi.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff --- Comment #18 from Emmi Takkinen <emmi.takkinen@koha-suomi.fi> --- (In reply to Emmi Takkinen from comment #17)
(In reply to Katrin Fischer from comment #16)
Hi Emmi, I just came across bug 35306 that seems to be related and maybe explains what we have been wondering about here.
So it seems and expiration date is now displayed as plain text. However with these patches expiration date changes.
Hmm, weird after several testes this doesn't happen anymore. Setting status back to "Needs Signoff". -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032 Esther Melander <esther.melander@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |esther.melander@bywatersolu | |tions.com --- Comment #19 from Esther Melander <esther.melander@bywatersolutions.com> --- I followed steps 1-7. At step 5 I set the DefaultHoldExpirationdate to 5 days. At the last step, when I revert the waiting status, the expiration date field is blank. I'm not sure if there were other system preference needed. If so, they should be specified. Also, after reverting the waiting status and refreshing the page, I got a bunch of errors: Can't call method "biblionumber" on an undefined value at /kohadevbox/koha/C4/Reserves.pm line 2158 I can attach the error trace, if that would help. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032 ByWater Sandboxes <bws.sandboxes@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #158516|0 |1 is obsolete| | --- Comment #20 from ByWater Sandboxes <bws.sandboxes@gmail.com> --- Created attachment 159908 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=159908&action=edit Bug 34032: Use reserves.patron_expiration_date if set If reserves.patron_expiration_date is set use it as holds expiration date when waiting status is reverted. To test: 1. Apply this patch. 2. Add hold for patron A and set expiration date manually. 3. Check in item on hold for patron A and confirm hold was set as waiting. 4. Revert holds waiting status. => Hold should still have expiration date you set manually in step 2. 5. Check that you have DefaultHoldExpirationdate and other DefaultHold sysprefs set. 6. Add hold for patron B, but this time do not set expiration date. 7. Check in item on hold for patron B, revert waiting status. => Hold should now have expiration date set based on DefaultHold sysprefs. Also prove t/db_dependent/Hold.t. Sponsored-by: Koha-Suomi Oy Signed-off-by: Esther <esther@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032 Esther Melander <esther.melander@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off --- Comment #21 from Esther Melander <esther.melander@bywatersolutions.com> --- My apologies. I forgot to hit save when changing the system preference for DefaultHoldExpirationdate. This does appear to work. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032 Kyle M Hall <kyle@bywatersolutions.com> 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=34032 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #152535|0 |1 is obsolete| | Attachment #159908|0 |1 is obsolete| | --- Comment #22 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 164823 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=164823&action=edit Bug 34032: Set new expirationdate if waiting status is reverted When one reverts holds waiting status holds expiration date is not set even if DefaultHoldExpirationdate syspref is enabled. This patch adds new param hold_reverted to be used when RevertWaitingStatus is used to determine if expiration date should be set again. To test: 1) Make sure you have DefaultHoldExpirationdate syspref enabled. 2) Find hold with status "Waiting". 3) Revert waiting status. => Note that hold has no expiration date set. 4) Apply this patch. 5) Repeat steps 2 and 3. => Expiration date should now be set based on reserve date. Also prove t/db_dependent/Hold.t. Signed-off-by: Sam Lau <samalau@gmail.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032 --- Comment #23 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 164824 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=164824&action=edit Bug 34032: Use reserves.patron_expiration_date if set If reserves.patron_expiration_date is set use it as holds expiration date when waiting status is reverted. To test: 1. Apply this patch. 2. Add hold for patron A and set expiration date manually. 3. Check in item on hold for patron A and confirm hold was set as waiting. 4. Revert holds waiting status. => Hold should still have expiration date you set manually in step 2. 5. Check that you have DefaultHoldExpirationdate and other DefaultHold sysprefs set. 6. Add hold for patron B, but this time do not set expiration date. 7. Check in item on hold for patron B, revert waiting status. => Hold should now have expiration date set based on DefaultHold sysprefs. Also prove t/db_dependent/Hold.t. Sponsored-by: Koha-Suomi Oy Signed-off-by: Esther <esther@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032 --- Comment #24 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 164825 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=164825&action=edit Bug 34032: (QA follow-up) Tidy code -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032 --- Comment #25 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Kyle, you forgot to add your sign-off lines :) Also re-tidied Holds.t for the QA script - maybe different versions of Perltidy at work here? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)| |24.05.00 released in| | Status|Passed QA |Pushed to main -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032 --- Comment #26 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Pushed for 24.05! Well done everyone, thank you! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032 Fridolin Somers <fridolin.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fridolin.somers@biblibre.co | |m Status|Pushed to main |Needs documenting --- Comment #27 from Fridolin Somers <fridolin.somers@biblibre.com> --- I prefer not to risk impact on stable branch 23.11.x -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org