wishlist: Consolidate patron notes, alerts, and messages

[Andrea Neiman]

This work is sponsored by the Evergreen Community Development Initiative (formerly MassLNC).

This work takes the existing Alerts, Notes, and Messages interfaces and collects them into one interface visible in the staff Patron area. Staff will now be able to enter all messages and penalties in this single interface, with a widget to indicate if the message is visible in the patron MyAccount interface. The Alert Message field currently available in Patron Edit will be removed, as will any extraneous interfaces.

An upgrade script will be included to migrate existing Alerts and Messages.

The full approved spec can be seen here:
https://yeti.esilibrary.com/dev/public/techspecs/consolidate_notes.pdf

A branch will be submitted to the community following partner testing.

[Jason Etheridge (phasefx)]

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/phasefx/consolidate_patron_notes

collab/phasefx/consolidate_patron_notes @ working/Evergreen.git

[Ruth Frasur Davis (redavis)]

Alerts added to a patron account are not causing the "alert splash screen" to come up when first going into that patron's account.

Also, error for failed checkout based on blocking alert is not descriptive.

[Ruth Frasur Davis (redavis)]

Screenshot of error message can be viewed here. https://drive.google.com/open?id=1WAiuLVVVKsLzEnK1_TwGQ9m9NSRqL_qI

[Dawn Dale (ddale)]

I agree with Ruth. The added alert did not cause the "alert splash screen" to come up when an alert was added. If I "display alerts" from the "Other" menu the alert is there.

When adding a message/note/alert there is no place for the staff member to enter there initials.

I would also like to know what happens to the old notes and alerts that were on the other screens in the staff client. Would it be possible to have some before accounts with alerts in the patron edit screen and alerts in the old "yellow" notes field so we can see how those are handled?

I do like the look and feel of the upgrade. I especially like the number of notes showing in the menu at the top of the screen. However, the number did not update when I added a new alert.

I am excited to see this coming to production!

[Ruth Frasur Davis (redavis)]

Update on my "error message" comment - I've found where/how that can be changed to be more descriptive. Please disregard.

I think that the alert screen issue is an ongoing browser issue. More testers/feedback would help clarify whether or not that should keep this from being signed off on.

[Terran McCanna (tmccanna)]

The alert screen has been discussed before, but I can't find the discussions right now. I believe the alert screen only appears the first time you open a patron account during a session. The assumption being, that after the first time you open the account you'll read them, and the red alert text will remind you of them if you open the account again during the same session.

[Michele Morgan (mmorgan)]

There is an open bug on the STAFF_CHR for the staff block that displays in the patron alert, bug 1631070.

Regarding the alert screen not popping up on concurrent patron retrievals, that issue exists in Evergreen now, independent of this development. If a different patron is retrieved before another retrieval of the test patron, the test patron's alerts will pop up. I thought I saw an open bug on this issue, but am unable to locate it now.

I don't think these two issues should preclude a signoff.

[Ruth Frasur Davis (redavis)]

Having fussed around with this more, I agree that none of this should preclude a signoff.

[Ruth Frasur Davis (redavis)]

I have tested this code and consent to signing off on it with my name, rfrasur, and my email address, <email address hidden>.

[Terran McCanna (tmccanna)]

I agree that the improved functionality is worth moving to even with the small side-issues. We would like to try running the conversion script for the pre-existing notes/alerts/etc on a PINES test server to verify that it runs well before committing though.

[Ruth Frasur Davis (redavis)]

Terran,

I think that's the best next step. Let me know if there's anything more I can.

[Bill Erickson (berick)]

Terran, checking to see if you had a chance to run the conversion script on your data.

[Andrea Neiman (aneiman)]

To facilitate future testing I'm including the documentation based off the branch as submitted.

[Terran McCanna (tmccanna)]

FYI, we applied to a test server with a copy of our real data on it last week and it broke patron search and checkout, causing the pages to not load completely. There was no obvious error in the web console, but we haven't had a chance to get back to it to troubleshoot where it failed.

[Terran McCanna (tmccanna)]

Since installing this code on a 3.4.2 PINES test server broke things, we tried it again on a fresh server with current master and Concerto data. To test, we set up the clean server, then added some notes, messages, and alerts to accounts before applying the new code and conversion script. Again, the code broke a lot of existing functionality (eg, the only account that could log in to staff client was admin, no accounts could log into OPAC, account edits produce errors...)

These are the alerts I added prior to applying the new code:
- alert added from patron edit screen
- note added, patron visible
- note added from penalties screen
- alert added from penalties screen
- block added from penalties screen
- alert, note, and block added from penalties screen and then archived

Problems Found with Old Converted Data:
-> Conversion made a patron visible note *not* patron visible, and did not record staff person who'd entered it. The Staff Alert, Label, and Penalty Name are also blank.
-> Converted notes have blank Org Depth - should they?
-> Alert that was moved from the patron edit screen to this interface gets a creation date of the date the script processed it. I think this is probably the way it should work, but staff will need to understand that those alerts are actually older than the date stamp. Maybe when those alerts are converted, a message could be appended to them saying "(Converted to new format during upgrade)" or something like that?

I then created some new notes of various types and visibility:
-> It would be helpful if double-clicking on a note would open in Edit (right now it does nothing, you have to use the Actions dropdown or right-click to open)
-> If a non-alerting note is present, it no longer indicates in the patron summary bar that there is a note - without that indicator, staff will have no idea there are notes present.
-> When creating a new note/alert/block, it defaults to the branch level. PINES needs this to default to the consortium level (especially for blocks). Maybe a new setting is needed?

Authentication / Account Problems Found:
-> I could not test the staff client with any type of account other than admin because login failed with every Concerto staff account I tried.
-> I could not test OPAC visibility of notes because all logins failed, including admin.
-> Tried editing accounts and got error "Patron Update Failed" every time.

[Terran McCanna (tmccanna)]

Forgot to add:

In summary, I believe that the conversion script is the likely culprit, because in earlier tests when we tested the patch on Concerto data with no conversion needed, we didn't see all of these problems.

[Jason Etheridge (phasefx)]

Thanks Terran! I'm looking at these.

[Jason Etheridge (phasefx)]

> Since installing this code on a 3.4.2 PINES test server broke things, we tried it again on a fresh server with current master and Concerto data. To test, we set up the clean server, then added some notes, messages, and alerts to accounts before applying the new code and conversion script. Again, the code broke a lot of existing functionality (eg, the only account that could log in to staff client was admin, no accounts could log into OPAC, account edits produce errors...)

Hrmm. Staff logins are working for me, but for patrons, I do see this for both editing patrons and trying to login as them:

ERROR: record "old" has no field "alert_message"

I see a missed alert_message field in the bowels of Storage, but that doesn't fix it. Hrmm. Okay, it's the functionality for preserving data in the auditor, which can get triggered during login when passwords are migrated to their new salted versions. I'll give that a look. Good catch!

> Problems Found with Old Converted Data:
> -> Conversion made a patron visible note *not* patron visible, and did not record staff person who'd entered it. The Staff Alert, Label, and Penalty Name are also blank.

I see the same. I've fixed the visibility part. Re: penalties and recording of the staff person, here's the situation: I kept all existing user messages in place (though neglected to flag them as public), and at the time only explicitly migrated private notes, with the thought that the public notes would be redundant (under the current scheme where the creation of a public patron note creates an associated user message). User messages currently do not record which staff created them.

So what we could do is, at upgrade time, try to link public patron notes with their associated user messages, based on matching user, message content, and timestamps (there's no explicit link, alas, and timestamp matching may have to be fuzzy). And then for public patron notes that we can't match (say, because the patron true deleted the associated user message), we can migrate the public patron note as archived, so that it doesn't show up for the patron, and so that staff still have a record of it. How does that sound? It doesn't match current behavior exactly, but current behavior is arguably non-ideal anyway (the split of notes into user messages). Staff Alert and friends would still be unset; there's really no need to create a standing penalty for these and that's the intended behavior you get when there is only a user message with the combined penalty/user-message view.

> -> Converted notes have blank Org Depth - should they?

No org depth, as long as they're still visible to everyone who needs to see them. Worse comes to worst, we could create SILENT_NOTE penalties to go with migrated notes that are not archived, but my preference is not to.

> -> Alert that was moved from the patron edit screen to this interface gets a creation date of the date the script processed it. I think this is probably the way it should work, but staff will need to understand that those alerts are actually older than the date stamp. Maybe when those alerts are converted, a message could be appended to them saying "(Converted to ne...

[Terran McCanna (tmccanna)]

Thanks, Jason! Your suggestions all sound good!

[Jason Etheridge (phasefx)]

A reminder of what's outstanding:
* at upgrade time, link public patron notes with their associated user messages
* at upgrade time, migrate unmatched public patron notes as archived
* title migrated alert messages to indicate their origin

And we should probably rebase against master at this point :)

[Jason Etheridge (phasefx)]

Also, related, bug 1859502

The fix for that was bundled into this branch, however we want to handle it.

[Jason Etheridge (phasefx)]

Also need to revisit auditor.

[Jason Etheridge (phasefx)]

Alright, I think I got everything at collab/phasefx/consolidate_patron_notes_rebased

Terran, if you have any more tuits, I'd appreciate another go.

Thanks!

[Terran McCanna (tmccanna)]

Excellent, thanks, Jason! I'll try to give this a thorough test during Feedback Fest (or before, if possible!)

[Mike Rylander (mrylander)]

I've added a sign-off to Jason's branch and followed up with one commit to make the upgrade fast(ish) on larger real-world data sets. Branch at:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/consolidate_patron_notes_rebased-upgrade_speed-signoff

[Terran McCanna (tmccanna)]

When applied to a copy of the PINES database, it takes 18 seconds or so to retrieve the consolidated notes, alerts, and messages. This appears to be caused by the check for deleted='f' in the SQL query. For some reason, this is causing the query to do a sequential scan rather than an index scan. In testing, removing the check for deleted='f' solves the performance issue and returns the results immediately.

IRC convo & pastebins showing the SQL results here:
http://irc.evergreen-ils.org/evergreen/2020-09-10#i_457943

Removing pullrequest for the moment, as the slow performance breaks the interface.

[Jason Etheridge (phasefx)]

Terran, et al.

I've pushed a rebased version of this with some fixes here:

collab/phasefx/consolidate_patron_notes2

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/phasefx/consolidate_patron_notes2

Please let me know if you run into any trouble with it.

[Joan Kranich (jkranich)]

Browser Chrome
https://festivus.evergreencatalog.com/eg/staff

I am able to create notes, specifically ALERT_NOTE when logged in as Admin.
I cannot create notes as Circulators or Circulation Administrator although both have permissions UPDATE_USER and VIEW_USER. It could be the depth or another restriction. I've attached the screen that displays when the login cannot create a note. The screen displays as if you could create a note but with an empty Penalty Type dropdown list. I find that display confusing to staff.

I've reviewed the earlier comments about the alert screen. When I bring up the patron record starting with Search for Patrons, the alert notes I've added at either the branch level or everywhere level do not display until I click on a function - Check Out, Holds, Notes, etc. After clicking on the function the alert displays in red in the patron summary.
I can see where staff may be searching for the patron that has a specific alert note such as they returned an item and it's a popular name. Staff would click on the patron names in the search results until locating the patron with the alert note so it would be helpful for the alert note to display at that point.

[Shannon Dineen (sdineen)]

Browser Chrome
https://festivus.evergreencatalog.com/eg/staff

Logged in as LSA on BR1. Scott Brock.
See SL1 test patron 99999303411.

(1) Can add and archive all 3 types of notes/alerts/messages successfully. Chose "This Branch" level. (default)
Tested widget to make patron visible or not, works well.

On Festivus OPAC test login as patron.
Messages display, look good. I can mark as read and delete no problem.

In staff client the display of notes deleted by patron may be confusing. There is an effectively empty line, and Deleted? column, if displayed, is blank, does not say Yes where I would expect it to. Undeleted messages say No in that column. See screenshot for display issue.

(2) I can confirm above report of messages not displaying on search results list when you click on a patron, nothing is displayed on left where I expect messages to show until I click on edit or check out etc.

(3) Error message on staff added circ block is vague : "Exceptions occurred during check out".

I am interested to know how this works on converted data as well.

[Jennifer Bruch (jbruchpails)]

This is a substantial change to patron data and a clean up project will be required both before and after this change.

How does this change affect the reporter module for this data?

Obviously, we will no longer need reports for different fields like we currently do, but in what fields does all this data land?

Is there enough test data on the test server to test this and is the reporter module turned on?

Thanks

[Andrea Neiman (aneiman)]

Hi Jennifer, Shannon, and Joan:

Thanks for testing. This work is available on the festivus.evergreencatalog.org test server hosted by Equinox (a full list of Feedback Fest test servers and credentials is here: https://docs.google.com/spreadsheets/d/1XeRK2oTIIu5pu7iy2ceWbE1ZRBgz9X2W1YC_E6QNexg/edit?usp=sharing)

I can't speak to the other servers but reporter is now running on festivus, and it is loaded with Concerto data for testing. I'm working on tidying up the docs for this work and I will post them shortly.

While everyone loves a good cleanup project, that's not necessary here. There is an upgrade script which will migrate existing notes into the new structure. Details about that, as well as table / column updates, can be seen in Jason's commit message: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=9056da4d90d8e357939e83216268b395788975fd

It is possible that some existing reports may need to be rewritten, depending on the kinds of reports your library has currently.

Regarding the placement of the Notes indicator, that was moved to the tab bar above the main patron area - there is now text reading "Notes" in between Bills and Edit, and if there are outstanding notes a counter will show here. In my testing I can see this counter when I click on the patron from the search results list.

I will look at the error messages, and deleted notes display. I have not been able to replicate the issue in Joan's screenshot but I'll keep trying.

Thanks all,
Andrea

[Andrea Neiman (aneiman)]

Docs draft here to facilitate testing:
https://docs.google.com/document/d/1SkcxGuYUc6LX02lPXcvF5C99Vj9mh08woWk0roZWL0s/edit?usp=sharing

Regarding the unfriendly error text, this is showing the name of the penalty - and tracks with what is current behavior. A possible follow up bug could be to make this & other penalty modals reference the label, instead of the name, since libraries are free to edit the label as needed.

I can confirm what Shannon sees with the deleted notes display and I'll confer more with Jason about that.

[Jennifer Bruch (jbruchpails)]

Played around in the reports on this and found quite a few changes.

The reports I created and their outputs are shared in the test system for you review.

The same data seems to be consistently fetched from the Standing Penalties and User Notes, though the fields for both have changed from original. Which route is better requires more debate. The Alert Message field in the ILS User Source is completely gone.

Notes on outputs and observed behaviors:

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?

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

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.

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.

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?

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

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

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.

Encountered in this scenario:
Created Blocks on Patron Barcode 99999395390 at BR4 and SYS2 Levels.
Logged out.
Logged back in at SL1 with sl1jpayton.
Enter patron barcode 99999395390 and submit.
There is the typical audible sound for the account loading, but the account does not load.

[Jennifer Bruch (jbruchpails)]

Hmmm, permissions issue? I am not familiar with how these accounts are set up so maybe this is expected behavior. Put if it is a permission issue it is failing without explanation in some cases and then showing the permission issue in others.

Ran into the same issue with 99999376669 at SL1 as sl1jpayton.

Stayed logged in as sl1jpayton but moved to a CON workstation and got a VIEW_USER permission denied.

Permission override attempt with Admin said it succeeded but still did not load the account.

Logged in as ADMIN at it showed account which does not have any blocks.

So it was not related to the blocks like I was wondering in my previous post.

[Dawn Dale (ddale)]

I have tested this code and consent to signing off with my name, Dawn Dale, and my email, <email address hidden>.

There are differences in the way this functions from the previous messages, however, I feel we should move on and consolidate now. Wish list items may arise and can be addressed at that point.

[Terran McCanna (tmccanna)]

(Note that the conversion script still needs to be tested on a large real data set.)

[Jason Etheridge (phasefx)]

re: not displaying alerts when navigating patrons in search, this is an existing bug in master. I didn't see a quick fix, so I think it should get its own ticket. Thanks!

[Jason Etheridge (phasefx)]

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

[Jason Etheridge (phasefx)]

Just noting that I can reproduce Jennifer's SYS2/SL1 bug in master using just penalties, so I'm going to open a separate bug for that one.

[Jason Etheridge (phasefx)]

I've pushed a rebased version to collab/phasefx/consolidate_patron_notes3

4dbea99f75d62e928d59477212a89e4bafc93482 lp1859502 fix A/T ApplyPatronPenalty reactor
3cb9a5c70c3b0bb3457c0823bbc4990110b4d558 lp1846354 toward consolidated patron notes
ed276069c2ebe8a6c9ca36e3dfa1d27234280bad LP#1846354 various speed improvements
4d9a562d4ae32b157bf55170bc5b84c5923ae73d lp1846354 revisions to upgrade script
a5925a9708f12734957950f5b9f77dd150e27b62 lp1846354 misc fixes

The last commit includes these changes:

    * don't hide referenced deleted messages from staff
    * don't exclude archived messages from unread Messages count in OPAC
    * migrate unmatched public notes as deleted user messages
    * don't use 'Penalty Note' as a message title

The very first commit has its own LP entry, bug 1859502. If committed here, we should close it out there, but this branch doesn't depend on it; I was just using the functionality for testing.

[Terran McCanna (tmccanna)]

We've tested the conversion script against a copy of the full PINES dataset and everything converted great! It took about 45 minutes to run the conversion, so I expect it will be shorter for most other libraries and consortia that run it.

We are very happy with this and looking forward to having it in our next upgrade!

I consent to signing off on this with my name, Terran McCanna, and email address, <email address hidden>.

[Galen Charlton (gmc)]

Noting that there are still some dangling references to actor.usr_note that need to be dealt with, including in the user merge and purge routines.

[Jason Etheridge (phasefx)]

Still looking this over, but the branch is now collab/phasefx/consolidate_patron_notes4

Rebased and new commits include:

commit c8177d5a2821b3498c7d70c43d4520806a5339a1
Author: Galen Charlton <email address hidden>
Date: Tue Mar 9 10:42:29 2021 -0500

    LP#1846354: update Angular new penalty dialog

    This patch ensures that the new Angular missing pieces interface
    can continue to create penalties. Additional work will be required
    on the Angular dialog to match the other changes.

    Signed-off-by: Galen Charlton <email address hidden>

commit 1aee47e8d0bd8f71c06d0df1b114c1c683f61284 (working/collab/phasefx/consolidate_patron_notes4)
Author: Jason Etheridge <email address hidden>
Date: Tue Mar 9 18:02:30 2021 -0500

    lp1846354 additional tweaks and fixes

    * fixes for SIP
    * patron merge & purge
    * also tweak some storage code, which probably isn't being used for this anywhere
    * remove some legacy note code
    * don't filter out penalties with deleted messages for Notes count in patron staff display

    Signed-off-by: Jason Etheridge <email address hidden>

[Chris Sharp (chrissharp123)]

Regarding Comment 40, I have just committed the fix to bug 1859502, so once this gets rebased, no need to include that in the branch.

[Jason Etheridge (phasefx)]

Thanks! Here's the rebase:

collab/phasefx/consolidate_patron_notes5 @ working/Evergreen.git

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/phasefx/consolidate_patron_notes5

[Dawn Dale (ddale)]

Alerts added by staff will not archive. They can be deleted and edited but not archived. At first I thought it was only the ones added in the patron edit screen alert field, but it appears to be any added by staff.

[Chris Sharp (chrissharp123)]

Seeing the server log messages attached, which may relate to what Dawn is seeing.

[Chris Sharp (chrissharp123)]

Further details:

2021-09-20 13:57:35 next-brick02-head open-ils.pcrud: [INFO:87025:osrf_application.c:1075:16321605478696228] CALL: open-ils.pcrud open-ils.pcrud.update.ausp "<REDACTED>",{"__c":"ausp","__p":[16679164,"2021-03-24T15:11:45-0400",1175852,402541,20,1,"now",16807997]}
2021-09-20 13:57:35 next-brick02-head open-ils.pcrud: [ERR :87025:oils_sql.c:7074:16321605478696228] open-ils.pcrud ERROR No "datatype" attribute for field "usr_message"

2021-09-20 13:57:35 next-brick02-head open-ils.pcrud: [INFO:86077:osrf_application.c:1075:16321605478696229] CALL: open-ils.pcrud open-ils.pcrud.update.aum "<REDACTED>",{"__c":"aum","__p":["2021-03-24T15:11:45-0400",null,1,16807997,"f","Clayton County Training 3/24/21 [ddale]",1175852,"Clayton County Training 3/24/21 [ddale]","f","now",null,null]}
2021-09-20 13:57:35 next-brick02-head open-ils.pcrud: [ERR :86077:oils_sql.c:7054:16321605478696229] open-ils.pcrud ERROR No "datatype" attribute for field "pub"
2021-09-20 13:57:35 next-brick02-head open-ils.pcrud: [ERR :86077:oils_sql.c:7054:16321605478696229] open-ils.pcrud ERROR No "datatype" attribute for field "stop_date"
2021-09-20 13:57:35 next-brick02-head open-ils.pcrud: [INFO:86077:osrf_app_session.c:1181:16321605478696229] [open-ils.pcrud] sent 377 bytes of data to <email address hidden>/_next-brick02-head_1632160547.637851_86962
2021-09-20 13:57:35 next-brick02-head open-ils.pcrud: [INFO:86077:osrf_stack.c:163:16321605478696229] Message processing duration 0.006667

[Dawn Dale (ddale)]

I have tested this code and consent to signing off on it with my name, Dawn Dale and my email address, <email address hidden>.

[Chris Sharp (chrissharp123)]

Pushed to master. Thanks everyone!