Staff Slips (UXPROD-19)

[UXPROD-3765] Add "Patron Group" as staff slip token Created: 02/Aug/22  Updated: 30/Nov/23  Resolved: 02/Feb/23

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

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

Issue links:
Defines
defines CIRC-1578 Add the field "requester.patronGroup"... Closed
defines CIRC-1579 Add the field "requester.patronGroup"... Closed
defines UICHKIN-347 Populate the token "requester.patronG... Closed
defines UICIRC-791 Add "Patron Group" as staff slip toke... Closed
defines UIREQ-804 Populate the token "requester.patronG... Closed
is defined by UXPROD-1830 Add additional USER tokens to staff s... Draft
Release: Orchid (R1 2023)
Epic Link: Staff Slips
Development Team: Volaris
PO Rank: 0
Rank: Cornell (Full Sum 2021): R4
Rank: Duke (Full Sum 2021): R1

 Description   

Current situation or problem: Librarians needs to see the patron group of the requestor on the staff slips.
This is one of the requests of UXPROD-1830

In scope: 

  • Adding a token to the staff slip template editor
  • Showing live data on a staff slip produced in the Requests app (pick slip)
  • Showing live data on a staff slip produced in the Check in app (hold, delivery request and transfer slips)

Out of scope: Any editing or computing of the live data populated in the token.

Proposed solution/stories:

  • UICIRC-791: Add "Patron Group" as staff slip token in Settings
  • CIRC-1578: Add the field "requester.patronGroup" to the Requester Object in the Staff Slip context, for pick slips generated in the Requests app.
  • CIRC-1579: Add the field "requester.patronGroup" to the Requester Object in the Staff Slip context, for hold, request delivery and transit slips generated in the Check in app.
  • UIREQ-804: Populate the token "requester.patronGroup" in the pick slip, with the data provided by the backend in the ui-requests module.
  • UICHKIN-347: Populate the token "requester.patronGroup" in the hold, request delivery and transit slips, with the data provided by the backend in the ui-checkin module.

Links to additional info

Questions



 Comments   
Comment by Erin Nettifee [ 08/Nov/22 ]

julie.bickle Tim Auger Duke really needs this to be in Poppy. Can we talk about whether that would be possible?

Comment by julie.bickle [ 09/Nov/22 ]

From my side, this is ready for dev; I'll leave it up to the team's lead PO to decide in which release it can go.

Comment by Tim Auger [ 10/Nov/22 ]

Erin Nettifee julie.bickle Learning time for me. Why is it important to add the patron group on staff slips? Is it one of those cases where services for faculty is different than everyone else?

Comment by Erin Nettifee [ 10/Nov/22 ]

Yes - this is how Duke would summarize the issue:

"Several Duke libraries depend on patron group appearing on a hold slip or pick slip to trigger workflows for faculty delivery. This includes Lilly and Music on East Campus, and Divinity, Ford and Law on West Campus.

FOLIO has implemented request delivery functionality that ideally would handle at least some delivery requirements, but it is not complete and doesn't meet basic requirements of being able to route to a final "delivery" service point. See https://folio-org.atlassian.net/browse/UXPROD-2429

Using faculty delivery as currently implemented in FOLIO would result in items being checked out to the patron at the first service point the item was checked in at, which is often not the delivery service point. Choosing to opt out of checking the item out to the patron at that point does not work either; the item remains in "Awaiting delivery" with no information about where the item should go next.

As such, we cannot use faculty delivery as currently implemented and really need to be able to tell from a slip who is a faculty member and who isn't. Without that, individual locations would need to maintain lists of faculty who have been getting item delivery to their offices, and expect staff to check those lists for every patron name when processing requests. That is simply not feasible given the volume of requests that are handled by part-time student staff; the error rate is just too high.

In addition, the "address fields" are only available on "request delivery" slips. Without having the office address field on the hold slip, it will be very difficult to determine where items need to be delivered."

So this is a response to other things in the project not being where we need them, but also talking about the general need.

Comment by Tim Auger [ 10/Nov/22 ]

Thank you, Erin Nettifee Makes complete sense and really brought back some memories for me as a student library working walking around campus delivery books and copied articles. Those were the days I relished!

 

Comment by Erin Nettifee [ 10/Nov/22 ]

Right - but hopefully it also makes clear why this is so important for our go-live – faculty delivery is not fully baked, but we still have to be able to do it. Honestly I'm really surprised it wasn't added as part of the initial group of user fields.

Comment by Tim Auger [ 10/Nov/22 ]

I would have expected it. There are other like design choices that I've seen that could have achieved more.

I added it to Poppy but we will probably pick it up for Orchid. 

Comment by Erin Nettifee [ 25/Jan/23 ]

Tim Auger julie.bickle should this feature be "In progress" since the stories are all being worked / in QA?

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

Nika Mindadze and Tim Auger 
I have checked the UI tickets, UICIRC-791 Closed , UICHKIN-347 Closed ,  UIREQ-804 , i.e. I have checked this feature from a UI perspective: the token behaves as expected in the staff slip template + in the slips themselves.

However, I am unable to check the BE tickets ( CIRC-1578 Closed , CIRC-1579 Closed ); I trust they work fine because the UI result is as expected.

How do you want me to go about updating/ closing the tickets? Is the process the same as for team Vega?

Comment by Tim Auger [ 02/Feb/23 ]

Wonderful julie.bickle You can close all of the tickets, even the backend. For these, it is a safe assumption that the UI is driven by the backend and non-happy path cases would have been tested by Nika Mindadze 

 

Thank you!

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

I confirm that this worked in Snapshot: I could see the patron group in the pick slip in Requests.

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