Bug 34263 - Suspending holds consecutively populates previously used date falsely
Summary: Suspending holds consecutively populates previously used date falsely
Status: Needs documenting
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Katariina Pohto
QA Contact: Testopia
URL:
Keywords:
Depends on: 36774
Blocks:
  Show dependency treegraph
 
Reported: 2023-07-12 18:13 UTC by Laura Escamilla
Modified: 2024-05-24 15:20 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
24.05.00


Attachments
Bug 34263: Suspending holds consecutively populates previously used date falsely (2.47 KB, patch)
2024-05-02 13:46 UTC, Katariina Pohto
Details | Diff | Splinter Review
Bug 34263: Suspending holds consecutively populates previously used date falsely (2.52 KB, patch)
2024-05-03 14:23 UTC, Pedro Amorim
Details | Diff | Splinter Review
Bug 34263: QA follow-up: Use flatpickr .clear instead (1.33 KB, patch)
2024-05-03 14:23 UTC, Pedro Amorim
Details | Diff | Splinter Review
Bug 34263: Suspending holds consecutively populates previously used date falsely (2.58 KB, patch)
2024-05-08 12:28 UTC, Nick Clemens (kidclamp)
Details | Diff | Splinter Review
Bug 34263: (QA follow-up): Use flatpickr .clear instead (1.39 KB, patch)
2024-05-08 12:28 UTC, Nick Clemens (kidclamp)
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Laura Escamilla 2023-07-12 18:13:56 UTC
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.
Comment 1 Katariina Pohto 2024-05-02 13:46:02 UTC
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.
Comment 2 Pedro Amorim 2024-05-03 14:23:04 UTC
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>
Comment 3 Pedro Amorim 2024-05-03 14:23:06 UTC
Created attachment 166141 [details] [review]
Bug 34263: QA follow-up: Use flatpickr .clear instead

Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com>
Comment 4 Pedro Amorim 2024-05-03 14:25:50 UTC
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.
Comment 5 Nick Clemens (kidclamp) 2024-05-08 12:28:15 UTC
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>
Comment 6 Nick Clemens (kidclamp) 2024-05-08 12:28:18 UTC
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>
Comment 7 Katrin Fischer 2024-05-08 16:25:01 UTC
Pushed for 24.05!

Well done everyone, thank you!
Comment 8 Pedro Amorim 2024-05-08 17:18:31 UTC
(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.
Comment 9 Katrin Fischer 2024-05-08 17:19:22 UTC
(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?
Comment 10 Katrin Fischer 2024-05-08 17:20:21 UTC
It's odd. The dependency should have been detected - I am looking into it.
Comment 11 Katrin Fischer 2024-05-08 17:37:24 UTC
(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.
Comment 12 Katrin Fischer 2024-05-08 17:46:59 UTC
I've decided to revert the patch, that gives us a clean state again to deal with the dependencies correctly.
Comment 13 Katrin Fischer 2024-05-08 17:52:15 UTC
Blocked by dependency waiting for QA.
Comment 14 Katrin Fischer 2024-05-10 12:12:54 UTC
Pushed for 24.05!

Well done everyone, thank you!
Comment 15 Fridolin Somers 2024-05-24 14:53:59 UTC
Depends on Bug 36774 not in 23.11.x
Comment 16 Pedro Amorim 2024-05-24 15:20:16 UTC
(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