Remove initials and date stamp from public copy notes display

[Kathy Lussier]

The display of initials and date stamp in the public copy notes display is ugly. See https://bark.cwmars.org/eg/opac/record/1899279. Christine Morgan at NOBLE whipped some code to use a regex to remove that information from the display. Her code and my signoff are available in a working branch at:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/kmlussier/remove-public-note-initials

[Tim Spindler (tspindler-cwmars)]

Kathy,

I think I would make a modification to this based on Dan Pearl's script. Christine's has an aggressive approach so that if you use a brackets as part of your note it would remove those also. We have notes that read

Pages [44-55] missing from the book [ts @ …

and the [44-55] could get stripped. Here is a suggested modification.

        [% IF copy_info.notes; %]
             [% FOREACH note IN copy_info.notes; %]
                 <tr><td>&nbsp;</td><td class="copy_note" colspan="4"><strong>[% note.title | html %]:</strong> [% note.value.replace('\[.*@.*\]\s*', '') | html %]</td></tr>
             [% END %]
         [% END %]

By using @ symbol, it is less aggressive.

[Thomas Berezansky (tsbere)]

If the information to be removed is always at the end of the note then adding a $ to the end of the replacement regex may help as well. That will prevent it from grabbing things mid-note, only removing from the very end.

If doing that it should be: note.value.replace('\[.*@.*\]\s*$', '')

[Tim Spindler (tspindler-cwmars)]

Good idea Tom.

[Thomas Berezansky (tsbere)]

To further limit it, for sanity purposes, we should not allow "leaving" the square brackets we are searching within. So something like this should prevent it from grabbing everything from the first square bracket to the end, hopefully only removing what we actually care about as a result:

note.value.replace('\[[^][@]*@[^][]*\]\s*$', '')

Given note.value of "This is a test [ some data ] more data [su 9/9/13 @ BR1]" we get different things with the different versions:

note.value.replace('\[.*@.*\]\s*', '') gives us "This is a test" - The same happens with the $ added, for the record.

note.value.replace('\[[^][@]*@[^][]*\]\s*$', '') gives us "This is a test [ some data ] more data"

[Jason Etheridge (phasefx)]

Do we want to bite the bullet and just make a dedicated field for this information? A one-or-few-time-use stored procedure could be fed a regexp like those being described to convert legacy data to the new schema. I really regret not pushing harder for dedicated fields here when this feature was implemented; I'd be willing to work on it.

[Dan Scott (denials)]

Jason: by all means, please do that! I was thinking the same thing...

[Kathy Lussier (klussier)]

+1 Jason

Distinct fields are definitely our preference. Would it be possible to store each piece (initials, date stamp, ou) in its own distinct field?

Thanks so much!

Kathy

[Jason Etheridge (phasefx)]

Kathy, that's definitely possible and is my preference. Thanks!

[Kathy Lussier (klussier)]

Nothing that this is also an issue with public patron notes using initials. Although these notes have always displayed initials, they became more visible when the public patron notes moved to the new message center.

Although I agree that the best solution is to move to distinct fields to store this information, I would advocate for putting a version of Christine's original code, with the suggested modifications and also applied to the patron notes, if it means we can get the display cleaned up sooner rather than later.

If others agree, then I can work on the branch over the next week.

[Galen Charlton (gmc)]

On Sun, Apr 12, 2015 at 6:24 PM, Kathy Lussier
<email address hidden> wrote:
> Nothing that this is also an issue with public patron notes using
> initials. Although these notes have always displayed initials, they
> became more visible when the public patron notes moved to the new
> message center.
>
> Although I agree that the best solution is to move to distinct fields to
> store this information, I would advocate for putting a version of
> Christine's original code, with the suggested modifications and also
> applied to the patron notes, if it means we can get the display cleaned
> up sooner rather than later.
>
> If others agree, then I can work on the branch over the next week.

+1 one for the sake of expedience, but I suggest including a prominent
comment in the template code about the nature of the work-around and
opening a new wishlist bug for splitting this stuff out into separate
fields.

[Jason Etheridge (phasefx)]

Hrmm, I let this ticket languish. Unassigning myself for now until I can grok it again.