Allow staff to delete read patron notes

[Jane Sandberg]

Steps to reproduce (courtesy of Jeremy Miller at Albany Public Library):

1. Staff adds a blocking note to a patron’s account (staff_chr is involved), and marks it public.
2. Patron logs into their account in OPAC, and reads the note.
3. Staff goes to edit or delete the note… and they can’t. It won’t let them.

This check for whether or not a patron has read the note can be found in the code here: https://github.com/evergreen-library-system/Evergreen/blob/4a6550fb9e7ce5570be4c627b86a1583aa0285d0/Open-ILS/web/js/ui/default/staff/circ/patron/app.js#L855

Per discussion on IRC, it seems that there was general agreement that staff should be able to delete a message, even if a patron has already read it. See http://irc.evergreen-ils.org/evergreen/2023-06-06#i_526947 . Two ideas were brought up as safeguards: a permission check and a confirmation alert in the client.

[Diane Disbro (ddisbro)]

Will patrons be confused when they look for a Read message in their account and it is no longer there?

[Terran McCanna (tmccanna)]

I have the same question/concern as Diane and Michele (in IRC) - what if a patron had wanted to keep that message? I've certainly had some patrons that would take this poorly.

And from the other side, why is it important for staff to be able to delete them? In my experience, manually created patron-visible messages are few and far in between, so I can't imagine that server space or performance are affected. If there are enough manual messages added to create issues, then there is probably a workflow problem.

I would urge a broader discussion with circulation staff/managers across different types of library systems before changing this behavior.

It would be nice to have a staff-side error message explaining why it can't be deleted, though.

(I'd need to check, but I'm pretty sure that staff can archive those notes even though they can't be deleted.)

[Andrea Neiman (aneiman)]

Confirming that the inability to delete patron messages was an intentional decision, for the reasons noted above as well as the (small but possible) "staff shenanigans" angle.

Not that this precludes changing things, of course, but just to clarify that this wasn't an oversight.

+1 to giving an error message to staff as Terran noted, though, explaining why they can't be deleted.

[Michele Morgan (mmorgan)]

In addition to patron visible notes manually added by staff for various reasons, our consortium also makes use of these notes via some action triggers:

- Patron account will expire soon
- Patron is billed for a long overdue item

At the beginning of COVID, we also used the patron visible notes to communicate closure information.

Patron visible notes can exist in a number of states. Deleting messages in some of these states makes perfect sense, with others it's less clear. These are the possible states of patron visible messages:

N - New or Unread by patron
R - Read by patron
D - Deleted by patron
NA - New or Unread by patron, Archived by staff
RA - Read by patron, Archived by staff
DA - Deleted by patron, Archived by staff

Notes in the following states are visible to the patron:

N
R
NA
RA

Notes in the following states can currently be deleted by staff:

N
D

It seems straightforward that notes in the DA state should be deletable by staff without need for any kind of prompt.

I would share the concerns raised above for the following states:

R
RA

Based on the additional discussion, if this moves forward, I would lean toward a permission to restrict deleting notes in the R and RA states. I can certainly think of circumstances when it would be appropriate to delete messages in the R or RA states, but I think it would be rare.

One more comment:

I think the ability for staff to remove N and NA should be consistent. In Angularjs no Archived messages can be removed by staff. In the New Angular Circ interface, Archived messages can be unarchived, but it shouldn't be necessary to unarchive a note just so it can then be deleted.