Bug 22922 - Allow to modify hold and hold expiration date in staff
Summary: Allow to modify hold and hold expiration date in staff
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Julian Maurice
QA Contact: Katrin Fischer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-05-16 10:12 UTC by Julian Maurice
Modified: 2021-06-14 21:29 UTC (History)
7 users (show)

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


Attachments
Bug 22922: Allow to modify hold dates on reserve/request.pl (4.12 KB, patch)
2019-05-16 10:14 UTC, Julian Maurice
Details | Diff | Splinter Review
Bug 22922: Allow reservedate changes only if AllowHoldDateInFuture is on (3.87 KB, patch)
2019-05-17 12:42 UTC, Julian Maurice
Details | Diff | Splinter Review
Bug 22922: Use jQuery datepicker instead of <input type="date"> (2.54 KB, patch)
2019-05-17 14:07 UTC, Julian Maurice
Details | Diff | Splinter Review
Bug 22922: Allow to modify hold dates on reserve/request.pl (4.15 KB, patch)
2019-05-17 18:11 UTC, Maryse Simard
Details | Diff | Splinter Review
Bug 22922: Allow reservedate changes only if AllowHoldDateInFuture is on (3.93 KB, patch)
2019-05-17 18:11 UTC, Maryse Simard
Details | Diff | Splinter Review
Bug 22922: Use jQuery datepicker instead of <input type="date"> (2.58 KB, patch)
2019-05-17 18:11 UTC, Maryse Simard
Details | Diff | Splinter Review
Bug 22922: (follow-up) Markup corrections (1.57 KB, patch)
2019-10-17 13:35 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 22922: Allow to modify hold dates on reserve/request.pl (4.23 KB, patch)
2019-10-18 06:22 UTC, Katrin Fischer
Details | Diff | Splinter Review
Bug 22922: Allow reservedate changes only if AllowHoldDateInFuture is on (4.01 KB, patch)
2019-10-18 06:22 UTC, Katrin Fischer
Details | Diff | Splinter Review
Bug 22922: Use jQuery datepicker instead of <input type="date"> (2.65 KB, patch)
2019-10-18 06:22 UTC, Katrin Fischer
Details | Diff | Splinter Review
Bug 22922: (follow-up) Markup corrections (1.63 KB, patch)
2019-10-18 06:22 UTC, Katrin Fischer
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Julian Maurice 2019-05-16 10:12:01 UTC

    
Comment 1 Julian Maurice 2019-05-16 10:14:51 UTC
Created attachment 89824 [details] [review]
Bug 22922: Allow to modify hold dates on reserve/request.pl

Test plan:
1. Place some holds
2. Go to the 'Holds' tab of the biblio record
3. Modify dates in the table and click on 'Update holds' button
4. Verify that dates have been correctly updated
Comment 2 Katrin Fischer 2019-05-16 19:16:52 UTC
What is the use case for changing the date the hold was placed? (allowing them to be in the future? And should this not depend on the syspref then?)
Comment 3 Owen Leonard 2019-05-17 11:54:06 UTC
(In reply to Katrin Fischer from comment #2)
> What is the use case for changing the date the hold was placed? (allowing
> them to be in the future? And should this not depend on the syspref then?)

I'm not sure what the use case is if you're *not* changing a hold date to/from a future date, but I think that's good enough reason to have the ability. Tying the operation to AllowHoldDateInFuture sounds right to me.
Comment 4 Julian Maurice 2019-05-17 11:56:14 UTC
Thanks for the feedback. I will write a followup soon.
Comment 5 Julian Maurice 2019-05-17 12:42:18 UTC
Created attachment 89896 [details] [review]
Bug 22922: Allow reservedate changes only if AllowHoldDateInFuture is on
Comment 6 Owen Leonard 2019-05-17 13:49:43 UTC
I realize that there is no aspect of the date selection process which requires specific features of the jQuery datepicker, but I think it should be used for consistency's sake.
Comment 7 Julian Maurice 2019-05-17 14:07:58 UTC
Created attachment 89902 [details] [review]
Bug 22922: Use jQuery datepicker instead of <input type="date">
Comment 8 Maryse Simard 2019-05-17 18:11:12 UTC
Created attachment 89915 [details] [review]
Bug 22922: Allow to modify hold dates on reserve/request.pl

Test plan:
1. Place some holds
2. Go to the 'Holds' tab of the biblio record
3. Modify dates in the table and click on 'Update holds' button
4. Verify that dates have been correctly updated

Signed-off-by: Maryse Simard <maryse.simard@inlibro.com>
Comment 9 Maryse Simard 2019-05-17 18:11:16 UTC
Created attachment 89916 [details] [review]
Bug 22922: Allow reservedate changes only if AllowHoldDateInFuture is on

Signed-off-by: Maryse Simard <maryse.simard@inlibro.com>
Comment 10 Maryse Simard 2019-05-17 18:11:20 UTC
Created attachment 89917 [details] [review]
Bug 22922: Use jQuery datepicker instead of <input type="date">

Signed-off-by: Maryse Simard <maryse.simard@inlibro.com>
Comment 11 Katrin Fischer 2019-06-02 14:09:51 UTC
This patch does a bit more than I thought - apart from changing the hold date, it also allows to change the expiration date. 

I think while the first should be controlled by the AllowHoldDateInFuture, the expiration date should not as it's already available to be set in the table now.
Note: the expiration date has a double use, it's used to say:
- Patron: I don't need this after... and also:
- Library: Hold needs to picked up until ...

Can you please change?

I am not sure about the consequences of this change. I think the date pickers are a bit too wide in the table. Adding Owen.
Comment 12 Owen Leonard 2019-08-23 11:48:42 UTC
(In reply to Katrin Fischer from comment #11)

> I think the date
> pickers are a bit too wide in the table. Adding Owen.

I usually give date input fields a size attribute of 10 on the assumption that is the maximum likely number of characters in a date: 0000-00-00
Comment 13 Katrin Fischer 2019-10-17 06:14:58 UTC
We only need a syspref check and some cosmetics here... please fix!
Comment 14 Julian Maurice 2019-10-17 07:18:21 UTC
(In reply to Katrin Fischer from comment #13)
> We only need a syspref check and some cosmetics here... please fix!

Which syspref and where ? attachment 89916 [details] [review] already checks AllowHoldDateInFuture
Comment 15 Katrin Fischer 2019-10-17 10:54:46 UTC
Seeing the pref check now... maybe it was only the width of the inputs missing then? (see comment#12)
Comment 16 Owen Leonard 2019-10-17 13:35:35 UTC
Created attachment 94372 [details] [review]
Bug 22922: (follow-up) Markup corrections

This patch adds a "size" attribute to the datepicker input fields and
adds self-closing "/".
Comment 17 Katrin Fischer 2019-10-18 06:22:31 UTC
Created attachment 94383 [details] [review]
Bug 22922: Allow to modify hold dates on reserve/request.pl

Test plan:
1. Place some holds
2. Go to the 'Holds' tab of the biblio record
3. Modify dates in the table and click on 'Update holds' button
4. Verify that dates have been correctly updated

Signed-off-by: Maryse Simard <maryse.simard@inlibro.com>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Comment 18 Katrin Fischer 2019-10-18 06:22:35 UTC
Created attachment 94384 [details] [review]
Bug 22922: Allow reservedate changes only if AllowHoldDateInFuture is on

Signed-off-by: Maryse Simard <maryse.simard@inlibro.com>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Comment 19 Katrin Fischer 2019-10-18 06:22:39 UTC
Created attachment 94385 [details] [review]
Bug 22922: Use jQuery datepicker instead of <input type="date">

Signed-off-by: Maryse Simard <maryse.simard@inlibro.com>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Comment 20 Katrin Fischer 2019-10-18 06:22:42 UTC
Created attachment 94386 [details] [review]
Bug 22922: (follow-up) Markup corrections

This patch adds a "size" attribute to the datepicker input fields and
adds self-closing "/".

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Comment 21 Katrin Fischer 2019-10-18 06:24:36 UTC
This is a rather small change, so I don't want to block it any longer. 

Just 2 things:
- There are no unit tests for the changes in Reserve.pm
- I am not sure all libraries will be happy about people being able to move the pick-up date, as there is also a fine penalty in some for not picking up your holds, but for the same reason: others will like it. If you get a call that someone needs some extra time, you can do that now.
Comment 22 Martin Renvoize 2019-10-21 09:01:33 UTC
Nice work!

Pushed to master for 19.11.00
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22922
bugs.koha-community.org
crawl=CC-MAIN-2022-33
63618
application/http; msgtype=response
sha1:VOL7TDHOUOIF5ZQUIG64IE7OZOS6WER3
<urn:uuid:cacabf65-10aa-4d30-a192-b35a926b6f64>
2022-08-16T23:23:13Z
72.14.190.217
text/html
sha1:IJWJ7ARZQGYHYKBYM3SATUTVQSJCEKFW
<urn:uuid:2bcea902-d74b-4bcb-a829-ea15686186bc>
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22922
response
<urn:uuid:0236c1ec-0ba3-4d31-84a7-a090b08e95b4>
isPartOf: CC-MAIN-2022-33
publisher: Common Crawl
description: Wide crawl of the web for August 2022
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-80
software: Apache Nutch 1.18 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.4-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/