Bug 24194 - Add system preference to disable the use of expiration dates for holds
Summary: Add system preference to disable the use of expiration dates for holds
Status: Signed Off
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Aleisha Amohia
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-12-09 20:23 UTC by Aleisha Amohia
Modified: 2022-12-16 17:24 UTC (History)
12 users (show)

See Also:
Change sponsored?: Sponsored
Patch complexity: Small patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
This enhancement adds a new system preference 'ReserveExpiration' which, when disabled, will remove the display and effect of expiration dates for holds.
Version(s) released in:


Attachments
Bug 24194: Add HideReserveExpiration system preference to hide expiration date options for reserves (7.75 KB, patch)
2019-12-09 20:46 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 24194: Add HideReserveExpiration system preference to hide expiration date options for reserves (7.85 KB, patch)
2019-12-09 21:41 UTC, ByWater Sandboxes
Details | Diff | Splinter Review
Bug 24194: Add HideReserveExpiration system preference to hide expiration date options for reserves (11.29 KB, patch)
2020-01-29 03:08 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 24194: Add HideReserveExpiration system preference to hide expiration date options for reserves (11.38 KB, patch)
2020-02-04 09:50 UTC, David Nind
Details | Diff | Splinter Review
Bug 24194: Add DisableReserveExpiration system preference to hide expiration date options for reserves (11.87 KB, patch)
2020-03-17 22:41 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 24194: Add DisableReserveExpiration system preference to hide expiration date options for reserves (16.06 KB, patch)
2020-09-14 23:25 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 24194: Add DisableReserveExpiration system preference to hide expiration date options for reserves (16.11 KB, patch)
2020-09-15 20:34 UTC, David Nind
Details | Diff | Splinter Review
Bug 24194: Add DisableReserveExpiration system preference to hide expiration date options for reserves (16.21 KB, patch)
2020-10-11 10:40 UTC, Katrin Fischer
Details | Diff | Splinter Review
Bug 24194: Add DisableReserveExpiration system preference to hide expiration date options for reserves (16.21 KB, patch)
2020-11-08 20:54 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 24914: (follow-up) Clarifying sysprefs, hiding columns, and more (10.21 KB, patch)
2020-11-08 20:54 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 24194: Add DisableReserveExpiration system preference to hide expiration date options for reserves (16.19 KB, patch)
2021-02-10 03:58 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 24914: (follow-up) Clarifying sysprefs, hiding columns, and more (10.49 KB, patch)
2021-02-10 03:58 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 24194: (follow-up) Renaming syspref to ReserveExpiration (14.23 KB, patch)
2021-02-18 22:04 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 24194: (follow-up) Correct some missing instances (15.74 KB, patch)
2021-02-19 13:43 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 24194: (follow-up) Link references to new preference (4.36 KB, patch)
2021-02-19 17:24 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 24194: Add DisableReserveExpiration system preference to hide expiration date options for reserves (16.34 KB, patch)
2021-02-19 22:00 UTC, David Nind
Details | Diff | Splinter Review
Bug 24914: (follow-up) Clarifying sysprefs, hiding columns, and more (10.59 KB, patch)
2021-02-19 22:00 UTC, David Nind
Details | Diff | Splinter Review
Bug 24194: (follow-up) Renaming syspref to ReserveExpiration (14.38 KB, patch)
2021-02-19 22:00 UTC, David Nind
Details | Diff | Splinter Review
Bug 24194: (follow-up) Correct some missing instances (15.88 KB, patch)
2021-02-19 22:00 UTC, David Nind
Details | Diff | Splinter Review
Bug 24194: (follow-up) Link references to new preference (4.51 KB, patch)
2021-02-19 22:00 UTC, David Nind
Details | Diff | Splinter Review
Bug 24194: Add DisableReserveExpiration system preference to hide expiration date options for reserves (16.34 KB, patch)
2021-03-16 01:41 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 24914: (follow-up) Clarifying sysprefs, hiding columns, and more (10.58 KB, patch)
2021-03-16 01:41 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 24194: (follow-up) Renaming syspref to ReserveExpiration (14.37 KB, patch)
2021-03-16 01:41 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 24194: (follow-up) Correct some missing instances (15.88 KB, patch)
2021-03-16 01:41 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 24194: (follow-up) Link references to new preference (4.50 KB, patch)
2021-03-16 01:41 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 24194: (follow-up) Use ReservesExpiration in other places (3.65 KB, patch)
2021-03-16 01:41 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 24194: Add DisableReserveExpiration system preference to hide expiration date options for reserves (15.92 KB, patch)
2021-12-07 04:09 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 24914: (follow-up) Clarifying sysprefs, hiding columns, and more (10.67 KB, patch)
2021-12-07 04:09 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 24194: (follow-up) Renaming syspref to ReserveExpiration (14.50 KB, patch)
2021-12-07 04:09 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 24194: (follow-up) Correct some missing instances (14.39 KB, patch)
2021-12-07 04:09 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 24194: (follow-up) Link references to new preference (4.54 KB, patch)
2021-12-07 04:09 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 24194: (follow-up) Use ReservesExpiration in other places (3.65 KB, patch)
2021-12-07 04:09 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 24194: (follow-up) Use ExpireReservesMaxPickUpDelay when setting hold waiting (3.52 KB, patch)
2021-12-07 04:09 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 24194: (follow-up) Throw an error if expiration date used (5.97 KB, patch)
2021-12-07 04:10 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 24194: Add ReserveExpiration system preference to disable expiration date options for reserves (36.32 KB, patch)
2022-09-15 04:12 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 24194: (follow-up) Throw an error if expiration date used (5.87 KB, patch)
2022-09-15 04:12 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 24194: Add ReserveExpiration system preference to disable expiration date options for reserves (36.35 KB, patch)
2022-11-18 16:56 UTC, Kyle M Hall
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Aleisha Amohia 2019-12-09 20:23:41 UTC
Some libraries do not need to set expiration dates for reserves (this functionality is used).
Add the ability to hide these options when placing reserves in staff client and OPAC.
Comment 1 Aleisha Amohia 2019-12-09 20:46:05 UTC Comment hidden (obsolete)
Comment 2 ByWater Sandboxes 2019-12-09 21:41:41 UTC Comment hidden (obsolete)
Comment 3 Jonathan Druart 2019-12-27 14:55:02 UTC
Should not it be hidden locally in CSS or JS instead?
Comment 4 Aleisha Amohia 2020-01-29 03:08:33 UTC Comment hidden (obsolete)
Comment 5 Aleisha Amohia 2020-01-29 03:10:00 UTC
(In reply to Jonathan Druart from comment #3)
> Should not it be hidden locally in CSS or JS instead?

It turns out the library wants to not use expiration dates for reserves at all, so the latest patch now includes not setting an expiration date when setting a reserve as waiting, and nullifying an expiration date when reverting waiting status. Back to needs signoff, with a new test plan.
Comment 6 Katrin Fischer 2020-01-29 07:12:44 UTC
(In reply to Aleisha Amohia from comment #5)
> (In reply to Jonathan Druart from comment #3)
> > Should not it be hidden locally in CSS or JS instead?
> 
> It turns out the library wants to not use expiration dates for reserves at
> all, so the latest patch now includes not setting an expiration date when
> setting a reserve as waiting, and nullifying an expiration date when
> reverting waiting status. Back to needs signoff, with a new test plan.

Hi Aleisha, can you please update the bug title? Sounds like quite a different thing now!
Comment 7 Aleisha Amohia 2020-01-29 19:55:36 UTC
(In reply to Katrin Fischer from comment #6)
> (In reply to Aleisha Amohia from comment #5)
> > (In reply to Jonathan Druart from comment #3)
> > > Should not it be hidden locally in CSS or JS instead?
> > 
> > It turns out the library wants to not use expiration dates for reserves at
> > all, so the latest patch now includes not setting an expiration date when
> > setting a reserve as waiting, and nullifying an expiration date when
> > reverting waiting status. Back to needs signoff, with a new test plan.
> 
> Hi Aleisha, can you please update the bug title? Sounds like quite a
> different thing now!

Fair enough Katrin, have updated!
Comment 8 David Nind 2020-02-04 09:50:40 UTC Comment hidden (obsolete)
Comment 9 David Nind 2020-02-04 09:53:02 UTC
I worked through the test plan and I think everything works as expected. But it may require sign-off or review from someone who is more familiar with holds/reserves!
Comment 10 Jonathan Druart 2020-03-17 14:46:10 UTC
It's much more than "hide"/"show". I think we should rename the pref and update its description to explain a bit more this new enhancement.
Comment 11 Aleisha Amohia 2020-03-17 22:41:42 UTC Comment hidden (obsolete)
Comment 12 Alex Arnaud 2020-06-26 08:04:29 UTC
Does not apply. Needs a rebase
Comment 13 Alex Arnaud 2020-06-26 08:09:11 UTC
I don't see any unit test that covers changes in the subs RevertWaitingStatus andset_waiting.
I think t/db_dependent/Reserves.t and t/db_dependent/Hold.t should be updated to take into account the new system preference.
Comment 14 Aleisha Amohia 2020-09-14 23:25:43 UTC Comment hidden (obsolete)
Comment 15 David Nind 2020-09-15 20:34:19 UTC Comment hidden (obsolete)
Comment 16 David Nind 2020-09-15 20:41:22 UTC
Hi Aleisha.

Everything worked for me a per the test plan, and the tests passed, so I have signed off.

Just a couple of things I noted, which are probably more for the QA team than me 8-) :

- Everywhere else in the UI it refers to holds rather than reserves: should the system preference name by HideHoldExpiration instead?

- For a patron, under Details > Holds the Expiration column is still shown. Should this be the case? (I'm not sure whether this is used for other holds/reserves things).

David
Comment 17 Katrin Fischer 2020-10-11 10:39:03 UTC
Comment on attachment 110127 [details] [review]
Bug 24194: Add DisableReserveExpiration system preference to hide expiration date options for reserves

Review of attachment 110127 [details] [review]:
-----------------------------------------------------------------

I had to fix a small conflict in the tests so I will upload an updated patch. Tests pass :)

(In reply to David Nind from comment #16)
> - Everywhere else in the UI it refers to holds rather than reserves: should
> the system preference name by HideHoldExpiration instead?

1) I think it would be nice to rename it at this stage, but as you can see below all the other prefs have Reserves in it too... so it might make it harder to find. But in the pref description we should switch from reserves to holds.

> - For a patron, under Details > Holds the Expiration column is still shown.
> Should this be the case? (I'm not sure whether this is used for other
> holds/reserves things).

2) Hm, I think this question highlights the thing that is not clear here for me about the intention of this patch and what the library has asked for. The expiration date field is (sadly) used for 2 different purposes in the life cycle of a hold:

a) Before the hold is filled, the date is used as "not needed after" indicating that the hold can be cancelled after a certain date if not filled.
b) After the hold is filled, the date is used for "pick up until" with a possible penalty if you don't or the hold going to the next patron with a hold after.

From reading the code, it looks like we are trying to remove the use of the expiration date altogether here (see change to set_waiting) - so both use cases/features. In this case I think more changes and tests would be needed:

- Hide it everywhere, expiration is still showing on the reserves page, the details and checkouts tabs in the patron account, etc. (see David's comment)
- Move the pref from the 'interface' section to 'hold policy' so it appears with the other prefs relying on the expiration date.
- Make the pref description a bit more explicit on its effects.
- Add notes to the system preferences relying on the hold expiration date: ExpireReservesMaxPickUpDelay, ExpireReservesMaxPickUpDelayCharge,  ExpireReservesOnHolidays, ReservesMaxPickUpDelay(?)
- Make sure misc/cronjobs/holds/cancel_expired_holds.pl doesn't cancel holds once the pref has been switched.

Personally I'd like it a little better if we dealt with a) and b) separately, starting with a) here. Both are separate features and mixing them in the db is not good design (see bug 21729).

Aleisha, can you clarify?

3) There is a fail in the QA script:

 FAIL	koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-reserve.tt
   FAIL	  valid_template
		Attempt to reload Koha/Template/Plugin/Branches.pm aborted.
Compilation failed in require at /usr/lib/x86_64-linux-gnu/perl5/5.24/Template/Plugins.pm line 206.

::: C4/Reserves.pm
@@ +2027,4 @@
>                             ->update({ priority => \'priority + 1' }, { no_triggers => 1 });
>  
>      ## Fix up the currently waiting reserve
> +    if ( C4::Context->preference('DisableReserveExpiration') ){

4) I think this is actually a general bug here - bug 21729 

On setting a hold to waiting, the expiration date changes from "not needed after" to "pick up before". So when we revert the waiting status, we'd want to reset to the date the patron chose as "not needed after", but it's already been lost/overwritten. :(

Should it maybe always be set to undef right now?

::: installer/data/mysql/atomicupdate/bug24194-add-DisableReserveExpiration-syspref.perl
@@ +1,3 @@
> +$DBversion = 'XXX';  # will be replaced by the RM
> +if( CheckVersion( $DBversion ) ) {
> +    $dbh->do(q{ INSERT IGNORE INTO systempreferences ( `variable`, `value`, `options`, `explanation`, `type` ) VALUES ( "DisableReserveExpiration", 0, NULL, "Disable the use of expiration date in reserves module.", "YesNo" ) });

Please make the reserves holds :)

::: installer/data/mysql/sysprefs.sql
@@ +163,4 @@
>  ('DefaultToLoggedInLibraryNoticesSlips',  '0', NULL ,  'If enabled,slips and notices editor will default to the logged in library''s rules, rather than the ''all libraries'' rules.',  'YesNo'),
>  ('DefaultToLoggedInLibraryOverdueTriggers',  '0', NULL ,  'If enabled, overdue status triggers editor will default to the logged in library''s rules, rather than the ''default'' rules.',  'YesNo'),
>  ('delimiter',';',';|tabulation|,|/|\\|#||','Define the default separator character for exporting reports','Choice'),
> +('DisableReserveExpiration', 0, NULL, 'Disable the use of expiration date in reserves module.', 'YesNo'),

Same here.

::: koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/circulation.pref
@@ +166,5 @@
> +            - pref: DisableReserveExpiration
> +              choices:
> +                  yes: Disable
> +                  no: "Don't disable"
> +            - the use of expiration dates in reserves.

And here.
Comment 18 Katrin Fischer 2020-10-11 10:40:23 UTC Comment hidden (obsolete)
Comment 19 Aleisha Amohia 2020-11-08 20:54:38 UTC Comment hidden (obsolete)
Comment 20 Aleisha Amohia 2020-11-08 20:54:42 UTC Comment hidden (obsolete)
Comment 21 Fridolin Somers 2020-11-09 07:22:56 UTC
Regarding to terminology https://wiki.koha-community.org/wiki/Terminology
We prefer hold instead of reserve.

New preference should be named 'DisableHoldExpiration' no ?
Comment 22 Aleisha Amohia 2020-11-09 20:13:22 UTC
(In reply to Fridolin Somers from comment #21)
> Regarding to terminology https://wiki.koha-community.org/wiki/Terminology
> We prefer hold instead of reserve.
> 
> New preference should be named 'DisableHoldExpiration' no ?

Hi Fridolin, Katrin has already answered this in the comment above:

1) I think it would be nice to rename it at this stage, but as you can see below all the other prefs have Reserves in it too... so it might make it harder to find. But in the pref description we should switch from reserves to holds.
Comment 23 Fridolin Somers 2020-11-12 10:45:10 UTC
Ok super ;)
Comment 24 David Nind 2020-12-07 21:09:21 UTC
Patch no longer applies 8-(
Comment 25 Aleisha Amohia 2021-02-10 03:58:08 UTC Comment hidden (obsolete)
Comment 26 Aleisha Amohia 2021-02-10 03:58:12 UTC Comment hidden (obsolete)
Comment 27 Owen Leonard 2021-02-18 13:56:44 UTC
I was looking at this and getting ready to submit a follow-up with some additional corrections (Holds history page, the holds tab on the checkout page, etc) but I find that it feels really convoluted to work with a system preference which is "negative." DisableReserveExpiration equals 1 to turn something off rather than turn something on.

I know this has been through a lot of revisions already but can it be switched to be "ReserveExpiration" and have it be enabled by default?
Comment 28 Aleisha Amohia 2021-02-18 22:04:22 UTC Comment hidden (obsolete)
Comment 29 Owen Leonard 2021-02-19 13:43:19 UTC Comment hidden (obsolete)
Comment 30 Owen Leonard 2021-02-19 17:24:28 UTC Comment hidden (obsolete)
Comment 31 David Nind 2021-02-19 22:00:10 UTC Comment hidden (obsolete)
Comment 32 David Nind 2021-02-19 22:00:13 UTC Comment hidden (obsolete)
Comment 33 David Nind 2021-02-19 22:00:17 UTC Comment hidden (obsolete)
Comment 34 David Nind 2021-02-19 22:00:21 UTC Comment hidden (obsolete)
Comment 35 David Nind 2021-02-19 22:00:25 UTC Comment hidden (obsolete)
Comment 36 Joonas Kylmälä 2021-02-22 14:12:06 UTC
ReserveExpiration should be moved out of set_waiting() method because it makes using set_waiting method really confusing because you are really expecting it to only set the waiting status and not do much more, documentation and testing of the function becomes also more difficult. The best way to do this would be to block adding expiration date already when creating a new hold. So please add the necessary code to OPAC, Staff and REST. For OPAC and Staff I see there is already some code, REST is missing completely. Also if I'm not mistaken the reason you added ReserveExpiration to set_waiting() is because of ReservesMaxPickUpDelay not working really well – what you could do here is do a DB upgrade so that ReservesMaxPickUpDelay value '' => 0 so then when ReservesMaxPickUpDelay is not an integer value it would simply not add expiration date.
Comment 37 Joonas Kylmälä 2021-02-22 14:15:52 UTC
(In reply to Joonas Kylmälä from comment #36)
> Also if I'm not mistaken the reason you added ReserveExpiration
> to set_waiting() is because of ReservesMaxPickUpDelay not working really
> well – what you could do here is do a DB upgrade so that
> ReservesMaxPickUpDelay value '' => 0 so then when ReservesMaxPickUpDelay is
> not an integer value it would simply not add expiration date.

Alternatively we could probably check if ExpireReservesMaxPickUpDelay is enabled and only then add the expiration date.
Comment 38 Joonas Kylmälä 2021-02-22 14:18:02 UTC
And for added robustness, you might wanna throw exception if somebody tries to set the expirationdate field for Koha::Hold.
Comment 39 Aleisha Amohia 2021-03-16 01:17:47 UTC
(In reply to Joonas Kylmälä from comment #36)
> ReserveExpiration should be moved out of set_waiting() method because it
> makes using set_waiting method really confusing because you are really
> expecting it to only set the waiting status and not do much more,
> documentation and testing of the function becomes also more difficult. 

I'm not sure I understand what you mean here, expiration date logic is already in the set_waiting method before my patch. I think moving that logic out is beyond the scope of this work. 

> The best way to do this would be to block adding expiration date already when
> creating a new hold. So please add the necessary code to OPAC, Staff and
> REST. For OPAC and Staff I see there is already some code, REST is missing
> completely. 

What code is missing for OPAC and staff? I will add it to REST in a follow-up.

> Also if I'm not mistaken the reason you added ReserveExpiration
> to set_waiting() is because of ReservesMaxPickUpDelay not working really
> well – what you could do here is do a DB upgrade so that
> ReservesMaxPickUpDelay value '' => 0 so then when ReservesMaxPickUpDelay is
> not an integer value it would simply not add expiration date.

I added it to set_waiting because the code already exists there - when we set a hold as waiting it may have a specified shelf time for awaiting pickup.
Comment 40 Aleisha Amohia 2021-03-16 01:41:00 UTC Comment hidden (obsolete)
Comment 41 Aleisha Amohia 2021-03-16 01:41:06 UTC Comment hidden (obsolete)
Comment 42 Aleisha Amohia 2021-03-16 01:41:10 UTC Comment hidden (obsolete)
Comment 43 Aleisha Amohia 2021-03-16 01:41:15 UTC Comment hidden (obsolete)
Comment 44 Aleisha Amohia 2021-03-16 01:41:20 UTC Comment hidden (obsolete)
Comment 45 Aleisha Amohia 2021-03-16 01:41:25 UTC Comment hidden (obsolete)
Comment 46 Joonas Kylmälä 2021-03-16 08:49:55 UTC
(In reply to Aleisha Amohia from comment #39)
> (In reply to Joonas Kylmälä from comment #36)
> > ReserveExpiration should be moved out of set_waiting() method because it
> > makes using set_waiting method really confusing because you are really
> > expecting it to only set the waiting status and not do much more,
> > documentation and testing of the function becomes also more difficult. 
> 
> I'm not sure I understand what you mean here, expiration date logic is
> already in the set_waiting method before my patch. I think moving that logic
> out is beyond the scope of this work.

I mean just moving the ReserveExpiration syspref code you added. The rest of the code is already in OPAC/INTRANET/REST (because that is required due the nature of it) so having this check there wouldn't add any extra code. Also please see below for more explanation.


Also note that this DB migration would be needed then:

> > ReservesMaxPickUpDelay value '' => 0 so then when ReservesMaxPickUpDelay is
> > not an integer value it would simply not add expiration date.


> > The best way to do this would be to block adding expiration date already when
> > creating a new hold. So please add the necessary code to OPAC, Staff and
> > REST. For OPAC and Staff I see there is already some code, REST is missing
> > completely. 
> 
> What code is missing for OPAC and staff? I will add it to REST in a
> follow-up.

You had the code to hide the HTML but if someone submits the request directly it will work but the expiration date is silently dropped. I noticed you handled it now this way as well in the REST API in the follow-up, IMHO there should be error given (e.g. raise the previously mentioned exception in Koha::Hold). Silently discarding data is going to lead to surprises for our API users especially!
Comment 47 Owen Leonard 2021-09-24 13:34:48 UTC
Marking "Failed QA" based on comment 46.
Comment 48 Aleisha Amohia 2021-12-07 04:09:29 UTC Comment hidden (obsolete)
Comment 49 Aleisha Amohia 2021-12-07 04:09:34 UTC Comment hidden (obsolete)
Comment 50 Aleisha Amohia 2021-12-07 04:09:39 UTC Comment hidden (obsolete)
Comment 51 Aleisha Amohia 2021-12-07 04:09:44 UTC Comment hidden (obsolete)
Comment 52 Aleisha Amohia 2021-12-07 04:09:49 UTC Comment hidden (obsolete)
Comment 53 Aleisha Amohia 2021-12-07 04:09:54 UTC Comment hidden (obsolete)
Comment 54 Aleisha Amohia 2021-12-07 04:09:59 UTC Comment hidden (obsolete)
Comment 55 Aleisha Amohia 2021-12-07 04:10:04 UTC Comment hidden (obsolete)
Comment 56 Aleisha Amohia 2022-09-15 04:12:48 UTC
Created attachment 140646 [details] [review]
Bug 24194: Add ReserveExpiration system preference to disable expiration date options for reserves

To test:
1) Update database
2) Go to place a hold on any biblio in the staff intranet and confirm you can see the 'Hold expires on date' field.
3) In another tab, go to place a hold on any biblio in the OPAC and confirm you can see the 'Hold not needed after' field as an option.
4) In yet another tab, open the staff intranet and place a reserve for a user. Check it in and set the reserve as waiting. Notice that an expiration date has now been generated for this reserve.
5) Attempt to check out the item you reserved to some other borrower. Revert waiting status. Notice that the expiration date that was generated remains.
6) Go to Administration -> system preferences and set ReserveExpiration system preference to 'Disable'
7) Refresh the hold request page in the intranet. Confirm the expiration date field disappears.
8) Refresh the hold request page in the OPAC. Confirm the expiration date field disappears.
9) Place another reserve. Check it in and set the reserve as waiting. Notice that no expiration date was generated for this reserve.
10) Attempt to check out the item you reserved to some other borrower. Revert waiting status. The expiration date should remain null.
11) Confirm tests pass
t/db_dependent/Hold.t
t/db_dependent/Reserves.t
12) Go to Admin -> System preferences and search for ReserveExpiration.
Confirm related system preferences have a reference to ReserveExpiration
and the links all work
13) Text the cancel_expired_holds.pl cronjob and confirm it works with
ReserveExpiration enabled, and does nothing when disabled
14) Confirm all instances where hold expiration dates are set or
referenced are shown or hidden correctly, depending on
ReserveExpiration

Pages in the staff interface:

- Check out to a patron and check the holds tab
- View patron details and check the holds tab
- Patron hold history
- Patron details -> Print -> Print summary
- Place a hold on a title which already has at least one hold on it,
  check the table of existing holds.
- Circulation -> Holds awaiting pickup

Pages in the OPAC:

- Log in to the OPAC as a patron with holds
  - Your summary -> Holds tab
  - Your holds history (OPACHoldsHistory must be enabled).

Sponsored-by: Horowhenua Library Trust

Signed-off-by: David Nind <david@davidnind.com>
Comment 57 Aleisha Amohia 2022-09-15 04:12:54 UTC
Created attachment 140647 [details] [review]
Bug 24194: (follow-up) Throw an error if expiration date used
Comment 58 Laura 2022-11-09 13:14:31 UTC
Signed-off-by: Laura Escamilla <lauraescamilla@bywatersolutions.com>
Comment 59 Kyle M Hall 2022-11-18 16:56:05 UTC
Created attachment 144076 [details] [review]
Bug 24194: Add ReserveExpiration system preference to disable expiration date options for reserves

To test:
1) Update database
2) Go to place a hold on any biblio in the staff intranet and confirm you can see the 'Hold expires on date' field.
3) In another tab, go to place a hold on any biblio in the OPAC and confirm you can see the 'Hold not needed after' field as an option.
4) In yet another tab, open the staff intranet and place a reserve for a user. Check it in and set the reserve as waiting. Notice that an expiration date has now been generated for this reserve.
5) Attempt to check out the item you reserved to some other borrower. Revert waiting status. Notice that the expiration date that was generated remains.
6) Go to Administration -> system preferences and set ReserveExpiration system preference to 'Disable'
7) Refresh the hold request page in the intranet. Confirm the expiration date field disappears.
8) Refresh the hold request page in the OPAC. Confirm the expiration date field disappears.
9) Place another reserve. Check it in and set the reserve as waiting. Notice that no expiration date was generated for this reserve.
10) Attempt to check out the item you reserved to some other borrower. Revert waiting status. The expiration date should remain null.
11) Confirm tests pass
t/db_dependent/Hold.t
t/db_dependent/Reserves.t
12) Go to Admin -> System preferences and search for ReserveExpiration.
Confirm related system preferences have a reference to ReserveExpiration
and the links all work
13) Text the cancel_expired_holds.pl cronjob and confirm it works with
ReserveExpiration enabled, and does nothing when disabled
14) Confirm all instances where hold expiration dates are set or
referenced are shown or hidden correctly, depending on
ReserveExpiration

Pages in the staff interface:

- Check out to a patron and check the holds tab
- View patron details and check the holds tab
- Patron hold history
- Patron details -> Print -> Print summary
- Place a hold on a title which already has at least one hold on it,
  check the table of existing holds.
- Circulation -> Holds awaiting pickup

Pages in the OPAC:

- Log in to the OPAC as a patron with holds
  - Your summary -> Holds tab
  - Your holds history (OPACHoldsHistory must be enabled).

Sponsored-by: Horowhenua Library Trust

Signed-off-by: David Nind <david@davidnind.com>