To recreate: 1. Place 3 holds on a patron account. 2. Suspend hold #1 and set date for 9/5/2023 or future date. 3. Suspend the hold for item #2. The pop-up modal shows a pre-filled suspend date of 9/5/23 (or the future date you chose). After confirming the suspend and returning to the holds list you'll see that no date shows up / the hold has been suspended indefinitely. 4. Suspend the hold for item #3. The pop-up modal has pre-filled the suspend date again to 9/5/23 (or future date used). However, re-selecting the date from the date picker correctly sets the date.
Created attachment 166069 [details] [review] Bug 34263: Suspending holds consecutively populates previously used date falsely The date picker and the hidden input field that saves the suspend date are two different fields. Using the Suspend button or the "Clear date to suspend indefinitely" link will only clear the hidden input field, and not the date picker. This will result in inconsistencies with what's seen on the date picker and what's actually set as the date value. This patch will change the functions for Suspend button the Clear date link to clear both the hidden input field and the date picker, so the dates are working consistently. The fields already had a unified class suspend-until but it was not used. Test plan: 1) Place 3 holds on a patron. 2) Suspend a hold and set a date for it. 3) Suspend a second hold and notice the previously used date is shown on the date picker. Note that the hold will be suspended indefinitely. 4) Open the suspending window for the third hold and pick a date. Click "Clear date to suspend indefinitely" and note the date picker doesn't get cleared. The hold will be suspended indefinitely. 5) Apply patch. 6) Suspend a hold and set a date for it. 7) Suspend a second hold and notice the date picker does not have a preset date. 8) Pick a date and clear it with the "Clear date to suspend indefinitely link". See that the date picker also gets cleared.
Created attachment 166140 [details] [review] Bug 34263: Suspending holds consecutively populates previously used date falsely Suspending a hold doesn't clear the date from the date picker. When another hold is suspended the previously used date will show on the date picker but the value is not set on the hold. Suspending the hold will suspend it indefinitely. Also the link "Clear date to suspend indefinitely" will not clear the date picker. This patch will make both the Suspend button and the Clear date link clear the dates from both the date picker and the variable passed on, making the suspending consistent with what is seen on the date picker. Test plan: 1) Place 3 holds on a patron. 2) Suspend a hold and set a date for it. 3) Suspend a second hold and notice the previously used date is shown on the date picker. Note that the hold will be suspended indefinitely. 4) Open the suspending window for the third hold and pick a date. Click "Clear date to suspend indefinitely" and note the date picker doesn't get cleared. The hold will be suspended indefinitely. 5) Apply patch. 6) Suspend a hold and set a date for it. 7) Suspend a second hold and notice the date picker does not have a preset date. 8) Pick a date and clear it with the "Clear date to suspend indefinitely link". See that the date picker also gets cleared. Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com>
Created attachment 166141 [details] [review] Bug 34263: QA follow-up: Use flatpickr .clear instead Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com>
Hi all, looking here. Testing notes: suspending the hold needs to be done from http://localhost:8081/cgi-bin/koha/members/moremember.pl?borrowernumber=19 (I was suspending holds from the biblio holds history and was having a hard time reproducing) I looked at this and thought "Why aren't we using flatpickr's clear() method instead?" and had a try myself. Found a bug with it and filed 36774. It turns out we resort to other .val("") for flatpickr instances elsewhere in the code and personally I don't think we should. Made this bug depend on the other one. Take a look at test yourself please.
Created attachment 166397 [details] [review] Bug 34263: Suspending holds consecutively populates previously used date falsely Suspending a hold doesn't clear the date from the date picker. When another hold is suspended the previously used date will show on the date picker but the value is not set on the hold. Suspending the hold will suspend it indefinitely. Also the link "Clear date to suspend indefinitely" will not clear the date picker. This patch will make both the Suspend button and the Clear date link clear the dates from both the date picker and the variable passed on, making the suspending consistent with what is seen on the date picker. Test plan: 1) Place 3 holds on a patron. 2) Suspend a hold and set a date for it. 3) Suspend a second hold and notice the previously used date is shown on the date picker. Note that the hold will be suspended indefinitely. 4) Open the suspending window for the third hold and pick a date. Click "Clear date to suspend indefinitely" and note the date picker doesn't get cleared. The hold will be suspended indefinitely. 5) Apply patch. 6) Suspend a hold and set a date for it. 7) Suspend a second hold and notice the date picker does not have a preset date. 8) Pick a date and clear it with the "Clear date to suspend indefinitely link". See that the date picker also gets cleared. Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com> Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Created attachment 166398 [details] [review] Bug 34263: (QA follow-up): Use flatpickr .clear instead Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com> Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Pushed for 24.05! Well done everyone, thank you!
(In reply to Katrin Fischer from comment #7) > Pushed for 24.05! > > Well done everyone, thank you! These patches require bug 36774 to be pushed first, ideally. Apologies here, I ended up blocking this bug with the flatpickr thing that I initially thought was a quick fix but ended up being a bit of a rabbit hole.
(In reply to Pedro Amorim from comment #8) > (In reply to Katrin Fischer from comment #7) > > Pushed for 24.05! > > > > Well done everyone, thank you! > > These patches require bug 36774 to be pushed first, ideally. > Apologies here, I ended up blocking this bug with the flatpickr thing that I > initially thought was a quick fix but ended up being a bit of a rabbit hole. Sorry, you commented when it was already pushed... maybe we can organize a quick QA?
It's odd. The dependency should have been detected - I am looking into it.
(In reply to Katrin Fischer from comment #10) > It's odd. The dependency should have been detected - I am looking into it. We figured that out: git bz didn't detect/warn about the dependency, because the dependent bug was temporarily moved back to ASSIGNED.
I've decided to revert the patch, that gives us a clean state again to deal with the dependencies correctly.
Blocked by dependency waiting for QA.
Depends on Bug 36774 not in 23.11.x
(In reply to Fridolin Somers from comment #15) > Depends on Bug 36774 not in 23.11.x From bug 36774: Fridolin Somers 2024-05-24 15:18:39 UTC Pushed to 23.11.x for 23.11.06 Which is it? =D
Oups good catch, thanks ;) Pushed to 23.11.x for 23.11.06
The QA follow up patch adds back in the pre-selected value on the datepicker for my 23.05.x Not backporting to 23.05.x