Add granular library settings for requiring staff initials on notes

Bug #1185148 reported by Ben Shum
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Wishlist
Unassigned

Bug Description

Evergreen master

So because public copy notes now show in the public catalog as of 2.4, we've noticed that having the library setting enabled for "Require staff initials of entry/edit of item/patron/penalty notes/messages." would cause it to make staff initials required and appended to every type of note. The format of the appended note statement would be something like [BTS 05/28/13 @LIBNAME] (aka, initials, date, @shortname). Specifically, we found this to be true for these three types of notes:

- patron penalties/messages
- patron information notes
- copy (item) notes

So, this bug ticket will track the creation of more granular library settings that will enable/disable requiring staff initials for each type of note individually rather than as a group. This allows us the use case of requiring staff initials be appended to patron notes and penalties, but not copy notes intended for public viewing.

An open question that's still under consideration is how to manage the original library setting. Do we create new entries for the settings we create based on the original setting to enforce continuing behavior? Should we just note the change in the RELEASE NOTES? Do we need to clean up and delete the original library setting since it should no longer be in use?

Working branch forthcoming...

Revision history for this message
Ben Shum (bshum) wrote :
Changed in evergreen:
milestone: none → 2.5.0-m1
importance: Undecided → Wishlist
Revision history for this message
Ben Shum (bshum) wrote :

Continuing work on this, moving to 2.5-m2 target instead.

Changed in evergreen:
milestone: 2.5.0-m1 → 2.5.0-m2
Dan Wells (dbw2)
Changed in evergreen:
milestone: 2.5.0-m2 → 2.5.0-alpha1
Remington Steed (rjs7)
Changed in evergreen:
milestone: 2.5.0-alpha1 → 2.5.0-alpha2
Revision history for this message
Ben Shum (bshum) wrote :

Moving this bug towards 2.5-beta1. I will be pushing a revised branch to resolve the upgrade issue by preserving existing functionality if set.

Changed in evergreen:
milestone: 2.5.0-alpha2 → 2.5.0-beta1
Dan Wells (dbw2)
Changed in evergreen:
milestone: 2.5.0-beta1 → 2.5.0-rc
Dan Wells (dbw2)
Changed in evergreen:
milestone: 2.5.0-rc → 2.next
Revision history for this message
Ben Shum (bshum) wrote :

So planning to revisit this bug for 2.next this time. If anyone has suggestions on the upgrade bits, I'm still interested in feedback.

Dan Wells (dbw2)
Changed in evergreen:
milestone: 2.6.0-alpha1 → none
Revision history for this message
Ben Shum (bshum) wrote :

Okay, finalized the upgrade script at long last based on some feedback I received from others. I also included a short release notes this time for the changes.

Latest, freshly rebased working branch at: user/bshum/staff-initials-granular-settings2

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/bshum/staff-initials-granular-settings2

Changed in evergreen:
milestone: none → 2.6.0-beta1
assignee: Ben Shum (bshum) → nobody
status: In Progress → Confirmed
tags: added: pullrequest
Dan Wells (dbw2)
tags: added: 2.6-beta-blocker
Changed in evergreen:
assignee: nobody → Mike Rylander (mrylander)
Revision history for this message
Mike Rylander (mrylander) wrote :

Looks great, Ben. Pushed to master!

Changed in evergreen:
status: Confirmed → Fix Committed
assignee: Mike Rylander (mrylander) → nobody
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.