When membership renewals come up for a patron, it would be useful for libraries to make a decision about automatic renewals of membership, based on current activity at the library. This would be a benefit/advantage for users who don't come into the physical branch but use curbside or electronic services. If Koha could look at borrowers.lastseen - last time a patron has been seen (connected at the OPAC or staff interface), this could be used as a way to identify that activity and renew the patron accordingly. In addition, if a library uses TrackLastPatronActivity the borrowers.lastseen date could also identify when a patron is using SIP-related connections. It would be great to have a system preference that would allow you to turn this function on or off for libraries who want patrons to come in to renew membership (ie show driver's license for mail verifying address). It would also be great to have a tie-in notice that automatically notifies them when they have been renewed!
I agree. I think this is a great idea so long as there is some kind of system preference to turn it on or off. Even better, though, would be to make it part of the circulation rules so that it could be turned on or off based on the borrower's home library or part of the patron category configuration so it could be turned on or off based on a borrower's category.
I like the sound of this. (It makes me wonder if all my library cards have expired since I haven't been to a public library since 2019 thanks to the pandemic*.) *I wonder if we'll look back one day on these Bugzilla comments and say "oh right... we did have a pandemic back then..."
This would be a great feature. We field countless calls/texts/emails from active patrons needing to renew their accounts. We've discussed extending the renewal period, but having it auto-renew based on activity would be much better.
Great idea. Is borrowers.lastseen the best way to detect activity, or should we look at holds or issues or ..?
(In reply to Marcel de Rooy from comment #4) > Great idea. Is borrowers.lastseen the best way to detect activity, or should > we look at holds or issues or ..? Bug 33245 provides a base for this. You can do $patron->is_active({ months => 6 }) or something and continue. The is_active method looks at datelastseen, enrollment date, expiry date, anonymized status, and recent holds, issues and article requests.
Note that bug 33522 provides another perspective: do not send expiry notices to inactive patrons. Might feel a bit less friendly, but could be an option too.
(In reply to Marcel de Rooy from comment #6) > Note that bug 33522 provides another perspective: do not send expiry notices > to inactive patrons. Might feel a bit less friendly, but could be an option > too. Decided to put this one on top of 33522.
Created attachment 152378 [details] [review] Bug 28688: Add new notice MEMBERSHIP_RENEWED Test plan: Run new install or upgrade. Check for this notice under Tools/Notices. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 152379 [details] [review] Bug 28688: Add renew option to membership_expiry.pl Test plan: [1] Pick an account to expire soon. [2] Choose MembershipExpiryDaysNotice so that it will be selected. (Note: You can extend the selection with -before or -after.) [3] Run misc/cronjobs/membership_expiry.pl -c -v -renew [4] Check new expiry date in the notice. Does it correspond with enrollment period of category and pref BorrowerRenewalPeriodBase? [5] If the patron category has an enrollment fee, check account too. [6] Reset dateexpiry of this patron to original date. [7] Run misc/cronjobs/membership_expiry.pl -c -v [8] Check if you got an expiry notice instead and dateexpiry did not change. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 152380 [details] [review] Bug 28688: Allow to pass another renewal notice Just as passing another expiry notice. Test plan: Pick a patron to expire. Create another membership renewal notice, say X. Run misc/cronjobs/membership_expiry.pl -c -n -v -letter_renew X Check output on command line. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 152381 [details] [review] Bug 28688: Add renewal to crontab example Note: I did not add an example to the debian cron daily file, since we have no commented lines there. And automatic renewal is no default behavior. Test plan: Read new lines in misc/cronjobs/crontab.example. Just comments. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
This works and see the contens of the MEMBERSHIP_RENEWED notice in the command line output. However I don't see the MEMBERSHIP_RENEWED notice in the message_queue. Ive tried with the default notice MEMEBERSHIP_RENEWED ( /misc/cronjobs/membership_expiry.pl -c -n -v -letter_renew MEMBERSHIP_RENEWED -renew ) and with a custom notice called X ( /misc/cronjobs/membership_expiry.pl -c -n -v -letter_renew X -renew )
(In reply to Lucas Gass from comment #12) > This works and see the contens of the MEMBERSHIP_RENEWED notice in the > command line output. However I don't see the MEMBERSHIP_RENEWED notice in > the message_queue. > > Ive tried with the default notice MEMEBERSHIP_RENEWED ( > /misc/cronjobs/membership_expiry.pl -c -n -v -letter_renew > MEMBERSHIP_RENEWED -renew ) > > and with a custom notice called X ( /misc/cronjobs/membership_expiry.pl -c > -n -v -letter_renew X -renew ) Thanks for testing, Lucas. I cannot reproduce this. I do see the notices in the message queue. I assume that you installed the dbrev, since you see output on the cmdline. Did you check if the patrons have a working email address?
Created attachment 155170 [details] [review] Bug 28688: Add new notice MEMBERSHIP_RENEWED Test plan: Run new install or upgrade. Check for this notice under Tools/Notices. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 155171 [details] [review] Bug 28688: Add renew option to membership_expiry.pl Test plan: [1] Pick an account to expire soon. [2] Choose MembershipExpiryDaysNotice so that it will be selected. (Note: You can extend the selection with -before or -after.) [3] Run misc/cronjobs/membership_expiry.pl -c -v -renew [4] Check new expiry date in the notice. Does it correspond with enrollment period of category and pref BorrowerRenewalPeriodBase? [5] If the patron category has an enrollment fee, check account too. [6] Reset dateexpiry of this patron to original date. [7] Run misc/cronjobs/membership_expiry.pl -c -v [8] Check if you got an expiry notice instead and dateexpiry did not change. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 155172 [details] [review] Bug 28688: Allow to pass another renewal notice Just as passing another expiry notice. Test plan: Pick a patron to expire. Create another membership renewal notice, say X. Run misc/cronjobs/membership_expiry.pl -c -n -v -letter_renew X Check output on command line. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 155173 [details] [review] Bug 28688: Add renewal to crontab example Note: I did not add an example to the debian cron daily file, since we have no commented lines there. And automatic renewal is no default behavior. Test plan: Read new lines in misc/cronjobs/crontab.example. Just comments. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Rebased on top of 33245/33522. PLEASE test !
Created attachment 155222 [details] [review] Bug 28688: Add new notice MEMBERSHIP_RENEWED Test plan: Run new install or upgrade. Check for this notice under Tools/Notices. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Created attachment 155223 [details] [review] Bug 28688: Add renew option to membership_expiry.pl Test plan: [1] Pick an account to expire soon. [2] Choose MembershipExpiryDaysNotice so that it will be selected. (Note: You can extend the selection with -before or -after.) [3] Run misc/cronjobs/membership_expiry.pl -c -v -renew [4] Check new expiry date in the notice. Does it correspond with enrollment period of category and pref BorrowerRenewalPeriodBase? [5] If the patron category has an enrollment fee, check account too. [6] Reset dateexpiry of this patron to original date. [7] Run misc/cronjobs/membership_expiry.pl -c -v [8] Check if you got an expiry notice instead and dateexpiry did not change. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Created attachment 155224 [details] [review] Bug 28688: Allow to pass another renewal notice Just as passing another expiry notice. Test plan: Pick a patron to expire. Create another membership renewal notice, say X. Run misc/cronjobs/membership_expiry.pl -c -n -v -letter_renew X Check output on command line. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Created attachment 155225 [details] [review] Bug 28688: Add renewal to crontab example Note: I did not add an example to the debian cron daily file, since we have no commented lines there. And automatic renewal is no default behavior. Test plan: Read new lines in misc/cronjobs/crontab.example. Just comments. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(In reply to Lucas Gass from comment #22) > Signed-off-by: Lucas Gass <lucas@bywatersolutions.com> Great!
I see this is signed off. This is a system preference our library branches are eager to see in place.
I think we should move the logic enrollment_fee logic to the notice template + $fees->{$recent->branchcode} = $recent->category->enrolmentfee if !exists $fees->{$recent->branchcode}; + $substitute->{enrollment_fee} = $fees->{$recent->branchcode} if $fees->{$recent->branchcode} > 0; It can be [% patron.category.enrolmentfee %], and we don't add black magic.
Hum, and why are you using the branchcode as the key of $fees?
Please clarify.
(In reply to Jonathan Druart from comment #26) > Hum, and why are you using the branchcode as the key of $fees? Thats a good question. It seems to be a typo. I do not recall another reason right now.
(In reply to Jonathan Druart from comment #25) > I think we should move the logic enrollment_fee logic to the notice template > > + $fees->{$recent->branchcode} = $recent->category->enrolmentfee if > !exists $fees->{$recent->branchcode}; > + $substitute->{enrollment_fee} = $fees->{$recent->branchcode} if > $fees->{$recent->branchcode} > 0; > > It can be [% patron.category.enrolmentfee %], and we don't add black magic. Will have a look.
Nice that both enrollmentfee and enrolment fee are correct spellings.. Please ignore that inconsistency here.
Created attachment 156522 [details] [review] Bug 28688: Add new notice MEMBERSHIP_RENEWED Test plan: Run new install or upgrade. Check for this notice under Tools/Notices. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Lucas Gass <lucas@bywatersolutions.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> [EDIT] Enrollment fee via object instead of substitute hash.
Created attachment 156523 [details] [review] Bug 28688: Add renew option to membership_expiry.pl Test plan: [1] Pick an account to expire soon. [2] Choose MembershipExpiryDaysNotice so that it will be selected. (Note: You can extend the selection with -before or -after.) [3] Run misc/cronjobs/membership_expiry.pl -c -v -renew [4] Check new expiry date in the notice. Does it correspond with enrollment period of category and pref BorrowerRenewalPeriodBase? [5] If the patron category has an enrollment fee, check account too. [6] Reset dateexpiry of this patron to original date. [7] Run misc/cronjobs/membership_expiry.pl -c -v [8] Check if you got an expiry notice instead and dateexpiry did not change. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Lucas Gass <lucas@bywatersolutions.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> [EDIT] Removed $fees and $substitute in favor of notice approach
Created attachment 156524 [details] [review] Bug 28688: Allow to pass another renewal notice Just as passing another expiry notice. Test plan: Pick a patron to expire. Create another membership renewal notice, say X. Run misc/cronjobs/membership_expiry.pl -c -n -v -letter_renew X Check output on command line. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Created attachment 156525 [details] [review] Bug 28688: Add renewal to crontab example Note: I did not add an example to the debian cron daily file, since we have no commented lines there. And automatic renewal is no default behavior. Test plan: Read new lines in misc/cronjobs/crontab.example. Just comments. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(In reply to Jonathan Druart from comment #25) > I think we should move the logic enrollment_fee logic to the notice template > > + $fees->{$recent->branchcode} = $recent->category->enrolmentfee if > !exists $fees->{$recent->branchcode}; > + $substitute->{enrollment_fee} = $fees->{$recent->branchcode} if > $fees->{$recent->branchcode} > 0; > > It can be [% patron.category.enrolmentfee %], and we don't add black magic. Removed the $fees and $substitute construct now and moved it to the notice.
New test result: +------------+-----------+----------------+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+--------------------+------------------------+---------+---------------------+---------------------+------------+-----------------------------+---------------+--------------+--------------+ | message_id | letter_id | borrowernumber | subject | content | metadata | letter_code | message_transport_type | status | time_queued | updated_on | to_address | from_address | reply_address | content_type | failure_code | +------------+-----------+----------------+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+--------------------+------------------------+---------+---------------------+---------------------+------------+-----------------------------+---------------+--------------+--------------+ | 513 | 173 | 50 | Account renewal | Dear Tommy Peters, Your library account has been renewed. The new expiry date is: 2032-01-04. An enrollment fee of $12.35 has been applied. Thank you, Your library, Springfield | | MEMBERSHIP_RENEWED | email | pending | 2023-10-04 11:47:28 | 2023-10-04 11:47:28 | NULL | noreply@master.rijkskoha.nl | NULL | NULL | | +------------+-----------+----------------+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+--------------------+------------------------+---------+---------------------+---------------------+------------+-----------------------------+---------------+--------------+--------------+
Created attachment 156533 [details] [review] Bug 28688: Add new notice MEMBERSHIP_RENEWED Test plan: Run new install or upgrade. Check for this notice under Tools/Notices. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Lucas Gass <lucas@bywatersolutions.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> [EDIT] Enrollment fee via object instead of substitute hash. Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Created attachment 156534 [details] [review] Bug 28688: Add renew option to membership_expiry.pl Test plan: [1] Pick an account to expire soon. [2] Choose MembershipExpiryDaysNotice so that it will be selected. (Note: You can extend the selection with -before or -after.) [3] Run misc/cronjobs/membership_expiry.pl -c -v -renew [4] Check new expiry date in the notice. Does it correspond with enrollment period of category and pref BorrowerRenewalPeriodBase? [5] If the patron category has an enrollment fee, check account too. [6] Reset dateexpiry of this patron to original date. [7] Run misc/cronjobs/membership_expiry.pl -c -v [8] Check if you got an expiry notice instead and dateexpiry did not change. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Lucas Gass <lucas@bywatersolutions.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> [EDIT] Removed $fees and $substitute in favor of notice approach Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Created attachment 156535 [details] [review] Bug 28688: Allow to pass another renewal notice Just as passing another expiry notice. Test plan: Pick a patron to expire. Create another membership renewal notice, say X. Run misc/cronjobs/membership_expiry.pl -c -n -v -letter_renew X Check output on command line. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Lucas Gass <lucas@bywatersolutions.com> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Created attachment 156536 [details] [review] Bug 28688: Add renewal to crontab example Note: I did not add an example to the debian cron daily file, since we have no commented lines there. And automatic renewal is no default behavior. Test plan: Read new lines in misc/cronjobs/crontab.example. Just comments. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Lucas Gass <lucas@bywatersolutions.com> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Created attachment 156537 [details] [review] Bug 28688: Use pod2usage for incorrect usage Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(In reply to Jonathan Druart from comment #41) > Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Great! Thanks
(Note that we should remove the Options part from the SYNOPSIS, it's redundant when you get the help message).
Created attachment 156540 [details] [review] Bug 28688: (follow-up) Remove redundant options Test plan: Run misc/cronjobs/membership_expiry.pl --help misc/cronjobs/membership_expiry.pl --man Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Pushed to master for 23.11. Nice work everyone, thanks!
Enhancement not pushed to 23.05.x
We are very excited about this update! Any possibility of backporting the update to 22.11?
(In reply to Kristi from comment #47) > We are very excited about this update! Any possibility of backporting the > update to 22.11? Hi Kristi, this is a new feature, inluding a new notice, and as such should not be backported to stable versions. This is also Frido as Rmaint of 23.05 decided and then it cannot go into even lower versions (waterfall principle).
Indeed, lots of changes here. This may introduce bugs in stable versions. 23.11 will be release soon :D