Optional Automatic Renewals for Items Out

Bug #1636923 reported by Jason Boyer on 2016-10-26
26
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Evergreen
Wishlist
Unassigned

Bug Description

From looking through the IRC logs, several locations have expressed an interest in a patron auto-renew feature where items will be renewed within X days of being due, provided renewals remain. I wanted to get this discussion going with some basic ideas on how it might be implemented and start listing the OUS (ugh) required to support it.

I would expect this to be built on the action/trigger system, which means at a minimum a new reactor (RenewCirc or similar), and possibly a new Validator to test whether a patron has opted in to auto renewals. A generic UserSettingValue validator that can also be used as desired in other A/T events is interesting. It could validate a setting named in the event environment against a value in the parameters so patrons can opt in or out (or you could use it in conjunction with OPAC visible settings to allow patron signup for newsletters, etc.) If there is already an accepted way to do that I'm not aware of it.

Then OUS to control it:
Does the library allow this feature at all?
A list of circ durations to attempt / avoid. It makes no sense to do this for hourly or short checkout periods. There may be a better way to determine this but circ duration is all that comes to mind at the moment. This may be better specified in the A/T config, but that's why we discuss things.

With all of that set up, I assume the success/failure messages for each transaction would be grouped together so users get only 1 message per day with the results of that day's autorenewals.

What problems do you see so far?

Mike Rylander (mrylander) wrote :

I see no problems per se, but I think there's a way to avoid adding a new validator. We already have opt-in user settings, which when set to true by the user allow an event to be created. You just attach the setting to the event definition, and the event is skipped if the user has not opted in by setting the value.

Jason Boyer (jboyer) wrote :

Thinking about this some more there's also not much reason for a yes/no OUS; it's not as if other A/T events need that. There's the active flag and an OU context so that's done. A better question would be "who" does the renewing and "where". The checkout staff and workstation from the existingcirc, a service account, etc.? I'm leaning toward just using the same values as the existing circ, though to prevent serious staff gaslighting there would need to be an automatic_renewal field to go with the existing phone, opac, and staff fields. If there's a strong desire to use a service account the default could be to use the existing circ values and override the specifics in the A/T parameters.

Jason Stephenson (jstephenson) wrote :

Why not treat this similar to an OPAC renewal, i.e. renewed by the patron at their home organization unit?

Kathy Lussier (klussier) wrote :

I agree with Jason that it should be handled similar to an OPAC renewal. However, I think it should also honor the circ.opac_renewal.use_original_circ_lib global flag to determine if it should be renewed by the home library or the circulation library. Or, since we already have two distinct flags for OPAC and desk renewals, maybe we need a distinct one for these renewals as well.

Jason Boyer (jboyer) wrote :

The short answer is that I forgot all about how opac renewals work. I think that is the right way to go after reconsidering. I do think an additional auto_renew field would be good to have in that case though so staff have some idea what is really going on.

Kathy Lussier (klussier) wrote :

I wanted to add a couple of other thoughts to this.

- I think we still might want to use an OU setting here. IIRC, the context in action triggers work a little differently than other settings. If you create this action trigger at the top of the org tree, but then a handful of libraries want to opt out, you essentially need to get rid of the consortium-wide one and create an action trigger for each library that wants to use it.

With OU settings, you can set True at the top of the org tree and then just set False for those handful of libraries that want to opt out.

- I thought this was mentioned in the original description, but I don't see it. If an automatic renewal fails because there is an outstanding hold or some other issue, we need to make sure there is a clear notification that goes out to the user, who may be so accustomed to the auto-renewals that they just assume it's going to happen.

Mike Rylander (mrylander) wrote :

While it's true that you can't use a global A/T definition when some libraries don't want it, that's simply how A/T is designed. A library adds what they need, rather than setting exceptions where they don't want something. The traditional way around this is to have a disabled global definition that you clone as needed. Cloning a definition is really no more difficult than setting a YAOUS, and has the benefit of local customization. Which leads to the second point ...

I can see three ways to manage a notification on failure:
 1) We could create a complex reactor is set up such that its logic just takes different paths depending on whether the renewal succeeds or fails, with the "success" path being "great, we're done here" and the "fail" path being "process the template and send it as email," then you'd probably want the ability to locally customize the template anyway.
 2) We could have the reactor trigger another hook ('circ.autorenew.failed', maybe) to be processed later, and each library could choose if and what to send on renewal failure, allowing customization.
 3) We could just use the Cleanup stage to process the definition's template and send a notification on failure. This is like (2) but without the extra event, and is locally customizable if it's not a global definition.

I prefer (3) with (2) as a second choice. I'm not a fan of overly complex reactors because doing to much in a reactor is bad for both bugs and cross-site usefulness (different strokes for different folks).

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers