Optional Automatic Renewals for Items Out

[Jason Boyer]

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)]

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)]

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)]

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

[Kathy Lussier (klussier)]

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)]

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)]

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)]

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).

[Jane Sandberg (sandbergja)]

Just throwing out an idea: what if the on/off switch were in the circ matrix, rather than in the org unit settings? My understanding is that library settings and action/triggers are based on the circulating library, rather than the library that actually owns the item *or* the patron's home library. In consortia that contain a mix of auto-renew and non-auto-renew libraries, I could see arguments for turning on/off both by item-owning library (to allay non-participating libraries' concerns that their materials could go to another system and get auto-renewed there forever) or the patron home library (to provide a consistent patron experience). The circ matrix is only place I can think of that would allow that flexibility.

[Josh Stompro (u-launchpad-stompro-org)]

Hello, a Minnesota library system (Hennepin County Library, non evergreen, running Horizon) just went live with auto renewal in 2018 and shared their experiences in a presentation at a conference last week. Here is a link to the presentation. It includes how the auto renewal feature affected their various stats for the first 3 months of 2018. It might be useful here since they discuss their various policy decisions also.
http://digitalcommons.macalester.edu/cgi/viewcontent.cgi?article=1657&context=libtech_conf

Josh

[Andrea Neiman (aneiman)]

Just to note, North Texas has contracted with Equinox to develop an autorenewals feature for Evergreen, though we will be taking a slightly different approach than outlined in this bug.

I'll post a new bug shortly and link it here.

[Jason Stephenson (jstephenson)]

Andrea, I'd prefer that this bug just be updated with a comment about the approach being taken by Equinox. Barring that, this bug should be made invalid or marked as a duplicate. I find all of the linking of "similar but different" bugs in the web staff client to be counter-productive.

[Andrea Neiman (aneiman)]

Duly noted Jason. Since conversation was starting on this bug ticket, I wanted to make sure the community knew that we will be working on this.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.