Patron Notices
(UXPROD-18)
|
|
| 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: |
|
||||||||||||||||
| 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. |
| 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. |
| 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: 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.
Also desirable:
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? |