Copy Alert Persistence and Suppression Matrix

Bug #1676608 reported by Galen Charlton on 2017-03-27
22
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Evergreen
Wishlist
Unassigned

Bug Description

Today, Evergreen provides two types of alerts for copy data: on-demand alerts that are displayed when an event occurs, such as the check-in of an item that has been marked Missing or Lost; and one-per-copy notification alert messages that are supplied by staff. Both alerts are presented to the user at check-in and checkout, with some exceptions, and staff intervention is required to force or stop the attempted action.

A new matrix of Alert Types and Events will be created, which will subsume the functionality provided by the current Alert Message and on-demand event alerting functionality. Staff will be able to attach multiple Alert Messages to a copy, and to define during which staff actions, such as check-in, checkout, and renew, those Alert Messages will be displayed. Staff will be able to mark each Alert Message as either Temporary or Persistent. Temporary Alert Messages will offer the alerted staff the option to Acknowledge the alert, at which time the Alert Message in question will be disabled, but not deleted, from the copy.

This will leverage the event matrix described above to generate a record of on-demand Alert Messages that occur at specific events. In addition, the ability to suppress the display of on-demand event alerts on a per-org-unit basis. Suppression will not prevent the generation of an event, but will instead act as if staff had intervened to force the attempted action. On-demand, system-generated alerts will be marked as temporary and auto-close, simply recording the fact of the alert. For direct checkout of Long Overdue items, a single new Org Setting will decided whether the preceding suppression-forced checkin will forgive fines or retain them. We will create a similar setting for Lost items.

Events will react to varying levels of granularity. Less granular events will be displayed at the time of any sub-events, whereas more granular alerts will be displayed only when applicable. For instance, "Non-renewal Check-in at Owning Library" Alert Types will only display when an item is checked in at it’s Owning Lib. However, general "Check-in" event alerts will display for each checkin event for an item, whether owning-library local or not, and even for renewal checkins.

Each ILS administrator with appropriate permissions will have the ability to associate one or more statuses with each Alert Type which, when used as a Temporary Copy Alert, will be presented to the alerted staff for use as the Next Copy Status, overriding the next natural status the copy would take. Persistent Alerts will not be able to make use of the Next Status values, if any are defined for the Alert Type. If one status is supplied by the administrator, that status will be applied to the copy after the Alert is processed, instead of the natural Next Status. If more than one Next Status is supplied, staff will be presented with the list to select from, with the first value in the list being selected by default. Suppressed on-demand events will not make use of the Next Status functionality. Only check-in event Alert Types will have associated logic that makes use of the Next Status selected by staff. Future development may add Alert Types for other events, such as the various transit types, or for events in the hold lifecycle. In that case, logic specific to those events would be added to make use of the Next Status selected by staff.

Finally, each Alert Type can be configured so that it will only display when the triggering event occurs at the owning or circulation library, or either.

Existing Copy Alert Message values will be copied and applied to new, stock Alert Types that occurs at non-renewal check-in and checkout, maintaining existing functionality. The Copy Alert field on the copy will then be cleared.

Full technical specifications for this feature are here:

http://yeti.esilibrary.com/dev/public/techspecs/alert-matrix.html

Galen Charlton (gmc) wrote :

The branch collab/gmcharlt/lp1676608_copy_alerts contains an implementation that has been tested by the library sponsoring work on this feature. The branch is rebased against master as of today, but is need in complete.

tags: added: alerts copies
Galen Charlton (gmc) wrote :

The last clause in my last comment should read "but is in need of some cleanup".

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

Duplicates of this bug

Other bug subscribers