Patron Notices (UXPROD-18)

[UXPROD-3769] Add "Preferred first name" as notice token Created: 03/Aug/22  Updated: 30/Nov/23  Resolved: 13/Feb/23

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: Orchid (R1 2023)
Parent: Patron Notices

Type: New Feature Priority: P3
Reporter: julie.bickle Assignee: Tim Auger
Resolution: Done Votes: 0
Labels: patron_notice
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Defines
defines CIRC-1585 Add the field "user.preferredFirstNam... Closed
defines MODFEE-316 Add the field "user.preferredFirstNam... Closed
defines MODNOTIFY-108 Populate the token "user.preferredFir... Closed
defines UICIRC-462 Add "user.preferredFirstName" as noti... Closed
is defined by UXPROD-1830 Add additional USER tokens to staff s... Draft
is defined by UXPROD-1831 Tokens - Add additional USER fields t... Draft
Relates
relates to UXPROD-3067 Display of Preferred name in Checkout... Closed
relates to UXPROD-3770 Add "Preferred first name" as staff s... Closed
Release: Orchid (R1 2023)
Epic Link: Patron Notices
Development Team: Volaris
PO Rank: 0
Rank: Cornell (Full Sum 2021): R2

 Description   

Current situation or problem: Libraries in the US often have a policy to refer to patrons by their preferred first name, rather than by their given name. 

User Story

As a public services staff member, I want all patron/user notices to use the patron preferred first name rather than given name.

History
Originally, this was requested on UXPROD-1830 Draft for staff slips, but I think it makes sense to also add this to notices.

In scope: 

  • Adding a token to the notice template editor
  • Hard-coding the logic to show EITHER preferred first name OR first name.
  • Showing live data on a notice.

Proposed solution/stories:

  • UICIRC-462: Add "user.preferredFirstName" as notice token in Settings
  • CIRC-1585: Add the field "user.preferredFirstName" to the User Object in the Notice context - in mod-circ
  • MODNOTIFY-108: Populate the token "user.preferredFirstName" in the notices, with the data provided by the context.

Update 6 Feb 23: Separate stories are needed for the notice template categories: "Manual fee/fine charge" and "Manual fee/fine action (pay, waive, refund, transfer or cancel/error)":

  • MODFEE-316: Add the field "user.preferredFirstName" to the User Object in the Notice context - in mod-fee-fines

 

Links to additional info

Questions



 Comments   
Comment by Erin Weller [ 23/Aug/22 ]

This is very important for Michigan State University. This is affecting our patrons who have given us their preferred names. We want to give them the best experience and using their legal name when they have given us a different name is not good service. We have been asked when this will be changed. Can this be worked on? Can we get an update on when it is expected to be done? Thank you!!

Comment by Tim Auger [ 15/Sep/22 ]

julie.bickle I hope you are doing well. A few questions:

-please review the user story I added in the description field. I wrote it from the perspective of the public services library staff. 

-when you use the term "notices" are you referring to only patron notices or, also, hold slips or transit or paging slips?  Not sure if FOLIO differentiates...

-why does "in scope" contain implementation details? Is that normal in community created stories?

Comment by julie.bickle [ 16/Sep/22 ]

Hi Tim Auger!

1_ I'm fine with that story.

2_ Notices = patron notices, currently only sent via email. Slips = ...  staff slips It's the same template engine, but it is two different UIs (Settings >> Circulation >> Patron notice templates  //  Staff slips) (and also BEs), and you can already see that the list of tokens is not exactly the same.

3_ That's a good question, to which I don't have a good answer. The Jira template for UXPROD features contains this section, and I looked at some previous notice work to decide how to populate it. I believed it can be used as a communication means, to be more explicit about what is in or not in the feature, and maybe serve as a check whether all the necessary stories have been written. This makes sense for very big features that end up needing to be split, I guess it doesn't really for a feature this size. If you think it's confusing or that this information is already available in the stories, please feel free to remove it.

Comment by Tim Auger [ 16/Sep/22 ]

Thanks for your answers, julie.bickle. Is there a reason Volaris shouldn't take UXPROD-3770 Closed as well?

Comment by julie.bickle [ 18/Sep/22 ]

Tim Auger No reason really and I see you have already done so.

Please don't hesitate to let me know, if you would like me to present the feature(s) to Volaris; I am always available for questions too.

Comment by Tim Auger [ 19/Sep/22 ]

sounds good, julie.bickle 

Comment by julie.bickle [ 06/Feb/23 ]

Hey Tim Auger,

Gurleen Kaur1 explained that, in actual fact, some work was do be done in a different module; I have capture this in this new story: MODFEE-316 Closed

Please decide which team takes this on + whether it can still be delivered in Orchid.

Comment by Gurleen Kaur1 [ 07/Feb/23 ]

Hi julie.bickle , Tim Auger ,
The code changes are done for MODFEE-316 Closed and once the PR is approved I shall merge it. 
Thanks.
CC: Arghya Mitra, Priyanka Terala 

Comment by julie.bickle [ 13/Feb/23 ]

Closing this feature, as the related stories are completed.

Generated at Fri Feb 09 00:34:39 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.