>STOP DATE - There is a Stop Date in two places in Standing Penalties, both do not appear to be fetching data. What circumstances would result in data here? Is it a nullability issue?

There's been a bit of evolution here, but the gist is that it's possible to have user messages without associated penalties, but the staff interface shows a unified view for both and we wanted some parity with functionality between the two.  stop_date is used by the Archive action, and the combined view will use the one associated with penalties if there is a penalty, otherwise it'll fall back to the one on the user message.

However, I found two related bugs looking into this.  One bug I'm noticing is that while public and archived messages still show up in My Account for patrons as intended, the Messages count/indicator is being erroneously subjected to stop_date.  I'll fix that.  The other is that in the upgrade script, we convert public patron notes to user messages if we could not find an existing user message to link to.  We erroneously set the stop date on these thinking they'd be hidden from the patron (the patron has likely already seen and deleted user messages that were created when these notes were originally created or set public).  Instead, we should create _deleted_ user messages for these.  That way they can still show up for staff (since we're also creating silent note penalties for them for other reasons) and not for the patrons.  Thanks!

>ORG DEPTH - Also appears empty. Is it a nullability issue?

This is the org depth associated with the standing penalty, which for a lot of them will be null.  With this work, the org depth for a standing penalty simply controls the default scope in the Create Note dialog.

>SYSTEM GENERATED PENALTIES - Can be edited and over written? YIKES! Observe the differences between Standing Penalties output 3 and 4. PATRON_EXCEEDS_FINES was generated but then overwritten by editing.

This matches existing behavior and probably warrants a separate bug entry.  The system will recreate penalties if needed as conditions change or the account is Refreshed.

>REALLY LONG NOTES - Start to be cut off in the pop up bubble, it cuts off the beginning of the message, not the end. Defining the character limit and then providing a counter to make sure staff mince their words might be advisable.

I think of the mouse-over behaviors as a convenience and wouldn't want to define a hard limit, though a warning might be a nice enhancement.  For alerts, the full text is still visible on the Display Alerts (aka stop sign) page, though for non-alerts, your only recourse is to edit the note to see the full text.  I think this is a small step backwards from the original notes interface, but it should be an edge case.  I think an alternate view of the Notes grid that resembles the Display Alerts page would be a good enhancement.

>DELETED VS ARCHIVED - There is a boolean Deleted field which I will assume means the note has been archived? Good for filtering out already handled messages but relabeling these would be nice in case there is ever a difference between deleted and archived. Oh, what about archived/deleted data that is converted? Are they included in the script and what would they look like?

So archived is powered by stop_date and should only do two things, stop penalizing for any penalties where the stop_date is set in the past, and shunt those listings into the Archive pane for the Notes interface.  It should not affect what the patron sees, but deleted will.  Staff should be able to see deleted user messages if there's still an associated penalty, but if the penalty gets true deleted (say, via Remove Note), then the deleted message will not be visible in the Notes interface, archived or otherwise.  However, the older Other -> Message Center can still view deleted user messages, and for now it'll be a function of the database administrator to handle true deletion of older data.

>READ DATE - What action prompts this field getting filled in?

This gets set when a patron reads a message in the OPAC; however, the patron has the ability to mark a message as unread, unsetting this field.

>ARCHIVED FILTER BUG - Stays fixed, changing the dates in filter fields seems reload the list.

Thanks!  Was it bug 1775940?

>ERROR LOADING ACCOUNT - Not sure what combination of things is causing this, perhaps the difference of login location and block message location? There is the typical audible sound for the account loading, but the account does not load.

Ah, good find!  For other developers, this is the string "undefined" being passed as the user ID to cstore.  I'll work on this.