Bug 32581 - Update dateexpiry on categorycode change
Summary: Update dateexpiry on categorycode change
Status: Patch doesn't apply
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Sam Lau
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-01-06 21:18 UTC by hebah
Modified: 2024-10-22 14:30 UTC (History)
11 users (show)

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


Attachments
Bug 32581: Automatically update patron expiration date when changing their category (4.26 KB, patch)
2024-07-03 20:18 UTC, Sam Lau
Details | Diff | Splinter Review
Bug 32581: Automatically update patron expiration date when changing their category (4.31 KB, patch)
2024-07-10 18:28 UTC, Roman Dolny
Details | Diff | Splinter Review
Bug 32581: Add confirmation modal (4.00 KB, patch)
2024-07-11 16:10 UTC, Sam Lau
Details | Diff | Splinter Review
Bug 32581: Automatically update patron expiration date when changing their category (4.36 KB, patch)
2024-07-12 12:08 UTC, Jan Kissig
Details | Diff | Splinter Review
Bug 32581: Add confirmation modal (4.04 KB, patch)
2024-07-12 12:08 UTC, Jan Kissig
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description hebah 2023-01-06 21:18:42 UTC
If you change a patron's category code, nothing checks whether their existing dateexpiry is valid for their category. An immediate renewal will correct this, but without that step, you could have someone move from a category with longer enrollment into a shorter enrollment period without anything prompting a check if that dateexpiry is still valid.
Comment 1 Suzanne 2023-01-12 20:24:09 UTC
Yes, without doing a renew on newly preregistered cards, it iss keeping the preregistration expiration date of 1 year, though a regular adult patron expires in 5 years. A preregistered 6 month non resident card is also keeping the 1 year. Changing a previous patron from an adult (5 years) to a non resident 6 month card would still leave them at the old expiration date. 

We would like to see changing a borrower type and saving it, add any applicable fees and update the expiration date, just by saving it.
Comment 2 Jaki 2023-12-12 17:44:17 UTC
We would love to see this change! Currently, our staff and part time substitutes often forget this step, which results in confusion for our staff and patrons. It would be nice if the expiration date automatically changed when the patron category is changed.
Comment 3 Suzanne 2024-05-22 01:58:24 UTC
I haven't seen any movement on this. Is it possible to look into a fix?
Comment 4 Sam Lau 2024-07-03 20:18:39 UTC
Created attachment 168476 [details] [review]
Bug 32581: Automatically update patron expiration date when changing their category

To test:
1) In Administration-> Patron categories, set the enrollment period for the 'School' category to 12 months.
2) Find a patron that is from another category, edit their info and change their category from patron to school.
3) Note that the expiry date automatically changes to 12 months from today.
4) Save your changes and ensure on the patron's detail page that their expiration date was successfully changed.
Comment 5 Roman Dolny 2024-07-10 18:28:54 UTC
Created attachment 168763 [details] [review]
Bug 32581: Automatically update patron expiration date when changing their category

To test:
1) In Administration-> Patron categories, set the enrollment period for the 'School' category to 12 months.
2) Find a patron that is from another category, edit their info and change their category from patron to school.
3) Note that the expiry date automatically changes to 12 months from today.
4) Save your changes and ensure on the patron's detail page that their expiration date was successfully changed.

Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Comment 6 Katrin Fischer 2024-07-11 08:31:53 UTC
This could pose a problem for libraries that charge library fees on renewal. A category change might happen for multiple reasons, we can not assume that for every library the renewal of the expiration date is correct.
I think it needs to be optional, maybe as a question to confirm/not confirm or a system preference
Comment 7 Sam Lau 2024-07-11 15:21:36 UTC
(In reply to Katrin Fischer from comment #6)
> This could pose a problem for libraries that charge library fees on renewal.
> A category change might happen for multiple reasons, we can not assume that
> for every library the renewal of the expiration date is correct.
> I think it needs to be optional, maybe as a question to confirm/not confirm
> or a system preference

Sure, that makes sense. So essentially the same thing that happens for the messaging preferences when you change your category?
Comment 8 Katrin Fischer 2024-07-11 15:23:52 UTC
I think that might work, but not completely sure what it looks like right now :)
Comment 9 Sam Lau 2024-07-11 16:10:34 UTC
Created attachment 168838 [details] [review]
Bug 32581: Add confirmation modal

This patch makes changing the expiration date optional, by providing a modal when switching a patron category. Confirming the modal will change the expiration date to the default and cancelling will keep the same expiration date.

To test:
1) Same plan as before except now there is a modal when changing the patron category.
- Attempt confirming the modal: expiration date should change to default.
- Attempt canceling the modal: expiration date should stay the same
Comment 10 Jan Kissig 2024-07-12 12:08:14 UTC
Created attachment 168895 [details] [review]
Bug 32581: Automatically update patron expiration date when changing their category

To test:
1) In Administration-> Patron categories, set the enrollment period for the 'School' category to 12 months.
2) Find a patron that is from another category, edit their info and change their category from patron to school.
3) Note that the expiry date automatically changes to 12 months from today.
4) Save your changes and ensure on the patron's detail page that their expiration date was successfully changed.

Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Jan Kissig <jkissig@th-wildau.de>
Comment 11 Jan Kissig 2024-07-12 12:08:17 UTC
Created attachment 168896 [details] [review]
Bug 32581: Add confirmation modal

This patch makes changing the expiration date optional, by providing a modal when switching a patron category. Confirming the modal will change the expiration date to the default and cancelling will keep the same expiration date.

To test:
1) Same plan as before except now there is a modal when changing the patron category.
- Attempt confirming the modal: expiration date should change to default.
- Attempt canceling the modal: expiration date should stay the same

Signed-off-by: Jan Kissig <jkissig@th-wildau.de>
Comment 12 Jan Kissig 2024-07-12 12:14:19 UTC
The patch works as described although I think there should be another bug to harmonize the 2 confirm dialogs. 
The first dialog which asks to accept the change of message preferences is a js confirmation dialog and fires only once.
It is followed by the new dialog which is in html and is fired every time the category id is changed.
Comment 13 Jan Kissig 2024-07-12 12:46:39 UTC
(In reply to Jan Kissig from comment #12)
> The patch works as described although I think there should be another bug to
> harmonize the 2 confirm dialogs. 
> The first dialog which asks to accept the change of message preferences is a
> js confirmation dialog and fires only once.
> It is followed by the new dialog which is in html and is fired every time
> the category id is changed.

Actually the first dialog also fires every time category id is changed
Comment 14 Sam Lau 2024-07-12 14:03:27 UTC
(In reply to Jan Kissig from comment #13)
> (In reply to Jan Kissig from comment #12)
> > The patch works as described although I think there should be another bug to
> > harmonize the 2 confirm dialogs. 

See Bug 31354
Comment 15 Tomás Cohen Arazi (tcohen) 2024-10-22 14:30:39 UTC
Doesn't apply. Please rebase. I feel like this could also be syspref-controlled.