Patron Notices (UXPROD-18)

[UXPROD-1007] Location settings should include contact info (email, phone, address) for use as tokens notices and slips Created: 17/Jul/18  Updated: 17/Aug/23

Status: In Refinement
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: Patron Notices

Type: New Feature Priority: P3
Reporter: Darcy Branchini Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: locations_uat_1, notice_tokens, patron_notice, round_iv
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to UXPROD-1599 Refine tokens, such as pickup locatio... Closed
relates to UXPROD-2156 Configure "from" and "reply-to" addre... Draft
relates to UITEN-161 Add additional fields to Settings -->... In Refinement
Potential Workaround: Darcy - Nice to have feature. Instead it can be added to each template by entering it and/or cutting and pasting from another file or template.
Epic Link: Patron Notices
Front End Estimate: XL < 15 days
Front End Estimator: Kostyantyn Khodarev
Back End Estimate: XL < 15 days
Back End Estimator: Kostyantyn Khodarev
Kiwi Planning Points (DO NOT CHANGE): 1
PO Rank: 30
Rank: Chalmers (Impl Aut 2019): R5
Rank: Chicago (MVP Sum 2020): R5
Rank: Cornell (Full Sum 2021): R4
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R2
Rank: FLO (MVP Sum 2020): R4
Rank: GBV (MVP Sum 2020): R1
Rank: Grand Valley (Full Sum 2021): R4
Rank: hbz (TBD): R1
Rank: Hungary (MVP End 2020): R1
Rank: Lehigh (MVP Summer 2020): R5
Rank: Leipzig (Full TBD): R1
Rank: MO State (MVP June 2020): R4
Rank: TAMU (MVP Jan 2021): R4
Rank: U of AL (MVP Oct 2020): R2

 Description   

Use Case: Email, phone and/or address will be used by institutions on patron notices. Institutions' needs vary. Most will use library addresses, but there might be a need for an institution or campus-level contact information as well.

Note: Several institutions ranked this high, but there is a work-around. The work-around is to cut & paste the information directly into each template instead of having a reusable token.

 

2-12-2021: Erin Nettifee and Darcy Branchini discussed this feature as well as UXPROD-2156 today. We decided it was worth revisiting the address feature built for Orders (in Settings --> Tenant --> General) to see if it could be expanded and possibly used for notice tokens. Erin will follow up with the Acquisitions PO to discuss further.



 Comments   
Comment by Darcy Branchini [ 21/Dec/18 ]

Is this only for patron notices? If so, it might make more sense to let template snippets or partials to cover this feature. I already have the concept of snippets for footer and signature. If we let the user define their own snippets, it will be more flexible.

Comment by Uschi Klute [ 20/Mar/19 ]

Darcy Branchini On patron notices there should be the specific address information for the item (e.g. for hold request notices), so a generally defined address snippet is not appropriate here.
I could imagine that a definition at library level is sufficient. Perhaps Anne L. Highsmith can tell us about their needs.

Comment by Anne L. Highsmith [ 20/Mar/19 ]

Your best source for an opinion on this would be the Resource Access SIG, of course. But I imagine that they would want an address at either library level or service-point level. Currently we use service point level addresses for circulation needs; we have 11 of them. We probably need the service point level address, because we certainly need to tell users where to return specific items and especially where to pick up items from requests, as Uschi says.

Comment by Uschi Klute [ 20/Mar/19 ]

In our current ILS we have the addresses on "department" level - which is between the library level and the service points. This fits all of our needs. In FOLIO we would like to have the addresses on service point level, I assume.

Comment by Cate Boerema (Inactive) [ 22/Mar/19 ]

Removing all but the essential features from the Q2 2019 Core Functional team backlog. After we've run the estimates through the cap plan, we may find we can pull in more.

Comment by Anya [ 29/Mar/19 ]

Comment from March Meeting : can you have the locations settings email, phone, - as a token ; FC/UA is okay with this because ICs will do the initial set up

Comment by Uschi Klute [ 26/Apr/19 ]

I think it is usefull to have the library address, phone numer and e-mail address at the Library level, too.
The location level adress data should then override the library level adress data.

Comment by Cate Boerema (Inactive) [ 27/May/19 ]

Darcy Branchini did you say you and some other POs had decided that the library address etc should not be collected as part of the location hierarchy? Is there a UXPROD describing the new plan?

Comment by Darcy Branchini [ 04/Jun/19 ]

Cate Boerema Appinteraction SIG was planning to consider our use cases when they were designing/developing contact information for orders and invoices, but decided to only develop it for their needs. I just found this out, so I'm going to need to design and write stories for this.

Comment by Erin Nettifee [ 09/Nov/21 ]

Holly Mistlebauer I'm reviewing this one again with the Prokopovych -> Vega circ modules work. I think for now, this one should stay with Prokopovych even though it's explicitly about notice functionality, because the work to store the attributes would be part of mod-inventory-storage. But there's a lot of unknowns about the approach here b/c there's really nothing in the notices logic that would allow this kind of thing to work (e.g., these would not just be additional tokens.) So yah - that's just to give it context here. I am going to leave the priority at P3 for now.

Comment by Uschi Klute [ 05/Jul/23 ]

Since the FOLIO full implementation of the GBV libraries is becoming more and more of an issue for us:
the suggested workaround "to cut & paste the information directly into each template" is not usable for many GBV libraries, because in this way the notifications are sent with identical content. This only works if there are no separate more or less independent sub-libraries.

However, if an institution is divided into such sub-libraries, which are located at different sites, then the notifications must contain the specific address information of the sub-library in question. 
This information is required:

  • Postal address (street, city, postal code)
  • E-mail address
  • Telephone number
  • Field for the name of a contact person (optional to be filled)

Also desirable: 

  • Field for the URL of the library website
  • Field for the URL to the Discovery System login screen

Presumably, this is a KO criterion for those GBV libraries with such an organised structure.

Erin Nettifee can this be included in the planning for the next flower releases?

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