Patron Notices
(UXPROD-18)
|
|
| Status: | Closed |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | Q2 2020 | Parent: | Patron Notices |
| Type: | New Feature | Priority: | P2 |
| Reporter: | Darcy Branchini | Assignee: | Darcy Branchini |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | cap-mvp, split | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||||||||||||||||||||||
| Epic Link: | Patron Notices | ||||||||||||||||||||||||||||||||||||
| Back End Estimate: | Medium < 5 days | ||||||||||||||||||||||||||||||||||||
| Back End Estimator: | Darcy Branchini | ||||||||||||||||||||||||||||||||||||
| Development Team: | Vega | ||||||||||||||||||||||||||||||||||||
| Rank: Chalmers (Impl Aut 2019): | R2 | ||||||||||||||||||||||||||||||||||||
| Rank: Chicago (MVP Sum 2020): | R1 | ||||||||||||||||||||||||||||||||||||
| Rank: Cornell (Full Sum 2021): | R2 | ||||||||||||||||||||||||||||||||||||
| Rank: Duke (Full Sum 2021): | R1 | ||||||||||||||||||||||||||||||||||||
| Rank: 5Colleges (Full Jul 2021): | R2 | ||||||||||||||||||||||||||||||||||||
| Rank: GBV (MVP Sum 2020): | R2 | ||||||||||||||||||||||||||||||||||||
| Rank: Lehigh (MVP Summer 2020): | R1 | ||||||||||||||||||||||||||||||||||||
| Rank: MO State (MVP June 2020): | R1 | ||||||||||||||||||||||||||||||||||||
| Description |
|
Problem: There are many steps in processing emails for patron notices, including: 1.) matching notice policies to location, material type, loan type and patron group using circulation rules; 2.) building emails from templates for each patron; 3.) running when scheduled; and 4.) sending to email service/server. An error might occur at any of those steps or the SMTP credentials might be incorrect or a bug or another issue might interfere with the processing of patron notices. Library staff need to know if notices are not being processed. Ideally they'd prefer to have visibility of errors or problems, but also successful statistics (i.e., how many were sent overnight). Description: In early discussions about this feature, we've identified a options and/or steps in order to improve this visibility of both successful and problematic processing of notices.
SPLIT: This feature is being split (April 2020) for each of these steps/options. Design will happen in Q2 with implementation happening in subsequent quarters. We are trying to include some of the implementation of the above in Q2. |
| Comments |
| Comment by Cate Boerema (Inactive) [ 27/Mar/20 ] |
|
Hi Darcy Branchini. I just updated the estimate to 5 days back end per discussion in our cap plan meeting. The idea was to treat this as a timeboxed spike for Q2 to identify the points of failure and make a plan (to be implemented later) |
| Comment by Darcy Branchini [ 14/Apr/20 ] |
|
Cate Boerema, Vega and I discussed this today and came up with several parts/ideas that go beyond simply notifying FOLIO admins of an error.
And one more step. I recently updated notice documentation, and Vega also alerted me to workflow and sequence diagrams as well as DB schema documentation that they have as PDFs. As a first step, they are updating those and merging those into the Google Doc documentation created in Q4. |
| Comment by Cate Boerema (Inactive) [ 15/Apr/20 ] |
|
Great. Thanks Darcy Branchini. Is the idea to create additional UXPROD(s) for the implementation of those features? I think we said that for Q2, we only had enough time to create a plan for future work. If that is still how we are proceeding, we probably should change the description of this UXPROD so folks don't think this will be fully addressed in Q2 (since this feature is assigned to Q2). Thanks! |
| Comment by Darcy Branchini [ 23/Jun/20 ] |
|
Instead Vega wants to use the Core Platform approach -
|