Wishlist: Cut off due dates so they don't extend past card expiration date

Bug #1046420 reported by Michael Peters
56
This bug affects 10 people
Affects Status Importance Assigned to Milestone
Evergreen
Confirmed
Wishlist
Unassigned

Bug Description

Small wishlist idea here. We used to have a legacy script for this, but sadly lost it. Discussed on IRC recently and many thought it was a good idea, so I'm filing this.

The general idea is that we would like the ability to "trim" loan periods when the expiration date of the card is drawing close.

So, lets say my card expires 9/12/2012 and I check out an item for 21 days on 9/5/2012. My due date should not be anytime after 9/12/2012 since my privileges are revoked on 9/12.

The optimal solution here is a YAOUS to toggle this behavior on/off as institutions wish. I imagine this will involve custom programming for the in-db circulation feature. It would also be awesome to have a legacy way of enabling this via the circ JavaScripts for stragglers (like us!).

Revision history for this message
Jeff Davis (jdavis-sitka) wrote :

We have implemented this on Sitka. Here's what it would look like in trunk:

http://git.sitka.bclibraries.ca/gitweb/?p=sitka/evergreen.git;a=commitdiff;h=c5060b264957707b12f03fe806c6adfa35d7a155

This adds two new org settings and some corresponding new behavior in Circulate.pm to handle circs where the patron's expiry date falls before the due date: the 'circ.limit_to_patron_expire_date' setting silently adjusts the due date to the patron's expiry date, while 'circ.warn_on_limit_by_expire_date' throws an error -- which means staff have to edit the patron's expiry date before proceeding.

As it stands, this doesn't allow you to throw a warning (or force a staff override) and proceed with the checkout anyway. So it doesn't really cover all cases. But it works for us.

Revision history for this message
Michael Peters (mrpeters) wrote :

Thank you for sharing, Jeff.

I gave it a try in 2.2.2 and am running into trouble.

osrfsys.log:[2012-09-06 11:36:44] /openils/bin/opensrf-perl.pl [ERR :28643:Application.pm:108:] Error loading application_implementation: OpenILS::Application::Circ -> Global symbol "$u" requires explicit package name at /usr/local/share/perl/5.10.1/OpenILS/Application/Circ/Circulate.pm line 2188.

Wondering if there is a prereq for this I may not have?

Revision history for this message
Jason Stephenson (jstephenson) wrote :

Looks more like a typo/thinko to me.

$U is often used as a shortuct for OpenILS::Application::AppUtils. Looks like it either has the wrong case, or needs to be declared with a "my."

Revision history for this message
Jeff Davis (jdavis-sitka) wrote :

I somehow managed to convert half that commit to lowercase. (Cue spooky X-Files music.)

Try this instead:

http://git.sitka.bclibraries.ca/gitweb/?p=sitka/evergreen.git;a=commitdiff;h=042599e180dbacc46b5af7880ea6d0261079de36

Revision history for this message
Michael Peters (mrpeters) wrote :

Thank you, Jeff! Works perfectly.

If you want to push it to the public working repo I will sign off on it as a potential new feature.

Dan Wells (dbw2)
Changed in evergreen:
assignee: nobody → Dan Wells (dbw2)
assignee: Dan Wells (dbw2) → nobody
Revision history for this message
Jeff Davis (jdavis-sitka) wrote :

Fix has (belatedly) been pushed to the working repo:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jeffdavis/lp1046420

We've had an request from our sites to add a popup warning when the due date is truncated, so I'll be building that onto this feature sometime soon.

Revision history for this message
Michael Peters (mrpeters) wrote :

Jeff -- I'm not having any luck getting the alert to pop up.

I've set my expiration date 1 day from today and checked out multiple items but never got the alert. YAOUS is configured TRUE at consortium and system levels.

Any ideas? Pulled from your most recent branch.

Changed in evergreen:
status: New → Triaged
Revision history for this message
Jeff Davis (jdavis-sitka) wrote :

This had dropped off my radar, but Jason Boyer has helpfully poked me about it. :)

For clarity, here is how this feature is intended to work. Given the two new settings, circ.limit_to_patron_expire_date and circ.warn_on_limit_by_expire_date, behavior should be as follows:

1) Limit is FALSE and WARN is FALSE: Due date is processed normally regardless of patron expiry date (this should be the default).

2) Limit is TRUE and WARN is FALSE: Due date is automatically truncated to expiry date.

3) Limit is TRUE and WARN is TRUE: A warning is given and then due date is automatically truncated to expiry date.
The warning message should be:
The patron account expires before the circulation due date. Due date has been truncated. Please update expiration date in patron account.

4) Limit is FALSE and WARN is TRUE: A warning is given and due date is processed normally.
The warning message should be:
The patron account expires before the circulation due date. Due date has been assigned normally. Please update expiration date in patron account.

Previously shared code will work in cases 1 and 2. I never got alerts working, so 3 and 4 aren't properly implemented yet. I'll take another look at that over the next few days.

Dan Scott (denials)
Changed in evergreen:
milestone: none → 2.7.0-alpha1
Revision history for this message
Ben Shum (bshum) wrote :

Moving this bug's milestone back to 2.next pending actual review into a development preview or release.

Changed in evergreen:
milestone: 2.7.0-alpha1 → 2.next
Revision history for this message
Michele Morgan (mmorgan) wrote :

Marking this as confirmed. I'd love to see this dusted off and implemented.

Changed in evergreen:
status: Triaged → Confirmed
Elaine Hardy (ehardy)
tags: added: circulation patron wishlist
removed: date due expire trim
Revision history for this message
Ruth Frasur Davis (redavis) wrote :

Not sure where this is in the lifespan of things, but noting that it is still an issue.

tags: added: needsrepatch
tags: removed: wishlist
tags: added: needsrebase
removed: needsrepatch
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.