Collections API should create a standing-penalty-based note

The open-ils.collections.put_into_collections API also applies the PATRON_IN_COLLECTIONS penalty. It's set to staff_alert=false in the stock data, though, and applies no blocks. Maybe we just need to change the seed data?

Locally we configure this penalty as staff_alert=true, block_list=CIRC|FULFILL|HOLD|CAPTURE|RENEW.

I agree with Bill that it makes sense to adjust the PATRON_IN_COLLECTIONS penalty in the seed data to make it alerting.

I note that the user note is not created as part of placing the patron into collections; instead, it's done via a separate call to open-ils.collections.patron_note.create.

However, I do see one caveat: the collections API doesn't seem to be doing anything to ever remove or close out the penalty, so if we make the penalty also blocking by default, we should deal with removing it (unless the assumption is that library staff members would always review and clear them?).

I agree with both Bill and Galen about the approach. For our use case, since the "0" depth of the penalty obscures which library put the patron into collections, I would want to see a note added indicating that. I'm working on a branch that makes that change that I'd love people's feedback on.

As to Galen's caveat, the assumption in PINES is that library staff remove the penalty, but I'm guessing some penalties are not being noticed since they aren't blocking things by default and don't show up for the libraries that didn't put the patron in collections.

If a non-zero penalty threshold is applied (representing $$ balance owed, in this case), the penalty is automatically removed by the penalty maintenance code (Penalty::calculate_penalties and actor.calculate_system_penalties).

To further clarify, PATRON_IN_COLLECTIONS is created via the collections API, but it's removed the same as a PATRON_EXCEEDS_FINES penalty, only presumably with a different threshold.

From some discussion in IRC, because I'm too lazy to retype it all...

[12:08:21] <miker> maybe I'm being too simple, but why not just show
the in-collections information as a stopsign alert? no need to
generate notes or anything, afaict
[12:09:03] <miker> as in, the list of orgs that have placed the user
in collections currently. it's there, it's authoritative...
[12:09:04] <berick> miker: i was musing the same thing
[12:09:14] <berick> and I think that's a better long-term solution
[12:09:28] <berick> use the data we have
[12:09:48] <miker> and easier, I'd think, than writing code to write
note (that will be ignored because notes are terrible ;) )
[12:10:27] <berick> well, UI dev is its own special thing (especially
with 2 active UI's) so I get the desire not to go down that path
[12:10:38] <berick> but, yeah..
[12:11:04] <berick> if we showed the tracker data, we could also show
dates applied
[12:11:15] <miker> I can attest that the stopsign page in webstaff is
not particularly hairy. it's the first preexisting one I touched :)
[12:11:16] <berick> and per-instance UMS notes (when they exist)

--
Mike Rylander
 | President
 | Equinox Software, Inc. / Open Your Library
 | phone: 1-877-OPEN-ILS (673-6457)
 | email: <email address hidden>
 | web: http://www.esilibrary.com

On Fri, Aug 26, 2016 at 12:00 PM, Bill Erickson <email address hidden> wrote:
> To further clarify, PATRON_IN_COLLECTIONS is created via the collections
> API, but it's removed the same as a PATRON_EXCEEDS_FINES penalty, only
> presumably with a different threshold.
>
> --
> You received this bug notification because you are a member of Evergreen
> Bug Wranglers, which is subscribed to Evergreen.
> https://bugs.launchpad.net/bugs/1617318
>
> Title:
> Collections API should create a standing-penalty-based note
>
> Status in Evergreen:
> New
>
> Bug description:
> Currently the open-ils.collections API creates an old-style patron
> note (actor.usr_note) on the patron account to indicate that the
> patron is in collections. These notes require several clicks to view,
> and aside from the "(See Notes)" indicator in the XUL client (not sure
> about the web client here), there is not a way for staff to know that
> a patron is in collections. My suggestion is that we add a new
> subroutine in Collections.pm that creates an ALERT_NOTE standing
> penalty that would show up when the patron record is accessed.
>
> I'm sure there's more to consider here, but that's what I've got at
> the moment.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1617318/+subscriptions

I mentioned to Jeff in a side conversation that the current behavior of the penalties/notes is resulting in a lot of extra manual work by PINES staff that would disappear if the penalties/notes worked as I've requested. Here's the current workflow for at least several (if not most) PINES libraries who use collections once they have a report from UMS of patrons added to collections:

For each patron put into collections:

1) Bar the patron (by clicking the "Barred" checkbox in the User Editor). Since per PINES policy, no other library can *un*-bar a patron that wasn't barred by them, this makes the patron have to pay the fine at the library that put them into collections.

[Side Note: "Bar" is really intended for serious offenses, like theft or harassment. Libraries are using it for this purpose basically because the software currently offers no alternative for this workflow]

2) Place a note in the patron account explaining the bar with enough information that other libraries know how to handle this.

For each patron who pays off their collections amount:

1) Remove the bar, delete the note, inform UMS.

The manual nature of this workflow is cumbersome and error-prone. If the collections penalty/notes worked the way requested here, there would be no need for barring and no need for managing manually-entered notes, freeing staff to do other tasks.

Please let me know if anything is unclear!

MassLNC has contracted with Equinox on a project to combine/streamline alerts & notes into a single interface, which will resolve most of this problem.

However, the collection API that creates the current note may need to be tweaked a bit once this work is complete in order to create the new type of message correctly.