Patron Notices (UXPROD-18)

[UXPROD-675] CRUD patron notice templates Created: 25/May/18  Updated: 16/Sep/20  Resolved: 14/Jan/19

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: Q4 2018
Parent: Patron Notices

Type: New Feature Priority: P3
Reporter: Darcy Branchini Assignee: Darcy Branchini
Resolution: Done Votes: 0
Labels: notices, resourceaccess, split
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PNG File 1 Patron notices - settings.png     PNG File 2 Patron notices - edit - predefined.png    
Issue links:
Blocks
is blocked by CIRCSTORE-68 endpoint for patron notice templates Closed
is blocked by MODLOGIN-55 Create mod-template-engine module Closed
is blocked by MODLOGIN-56 Add CRUD REST to mod-template-engine Closed
Relates
relates to UICIRC-70 Settings for patron notice templates Closed
relates to UICIRC-74 Patron notices - email templates Closed
relates to UICIRC-85 Delete custom patron notice template ... Closed
relates to UICIRC-86 Create, edit and clone patron notice ... Closed
relates to UICIRC-87 Read/view patron notice template Closed
relates to UICIRC-117 Patron notices - templates for text o... Closed
relates to UICIRC-118 Patron notices - templates for printe... Closed
relates to UXPROD-1392 Extend patron notices to print Draft
relates to UXPROD-1393 Extend patron notices to SMS Draft
Epic Link: Patron Notices
Analysis Estimate: Large < 10 days
Analysis Estimator: Darcy Branchini
Front End Estimate: XL < 15 days
Front End Estimator: Michal Kuklis
Back End Estimate: Very Small (VS) < 1day
Back End Estimator: Jakub Skoczen
Estimation Notes and Assumptions: CB: Per slack chat with Matt Connolly, "I think that the back-end work is being handled by the mod-template-engine team (Folijet), so the Core team work should be minimal either way." Given that, I have reduced the BE estimate from XXL to Large (30 to 10 days). I'd like the developers to adjust further, as-needed, but I needed to make an initial adjustment now for planning.
CB: Per Jakub, this can be further reduced to 1 day for BE. Jakub also thinks we should increase the front end from 5 to 15.

Development Team: Prokopovych
Rank: BNCF (MVP Feb 2020): R1
Rank: Chalmers (Impl Aut 2019): R1
Rank: Chicago (MVP Sum 2020): R1
Rank: Cornell (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R1
Rank: GBV (MVP Sum 2020): R1
Rank: Lehigh (MVP Summer 2020): R1
Rank: TAMU (MVP Jan 2021): R1
Rank: U of AL (MVP Oct 2020): R1

 Description   

Basic create, read, update and delete functionality (as well as clone or duplicate) for patron notice templates. They'll need to be configurable from settings > circulation > patron notices and a patron notice will have the following fields name, description, active/inactive toggle and templates.

Notes:

  • Some notices will be "out of the box" and therefore not deletable. Users will still be able to designate them as "active" or "inactive" and should be able to clone them too.
  • General configuration has not been fully defined, but will include the ability to specify whether or not print notices will be sent.
  • See UXPROD-110 for earlier reference to patron notices, and UXPROD-723 Closed for more details on templates.

Details on Templates ( UXPROD-723 Closed has been merged with this and closed as a duplicate):

Need the ability to define email, sms (text) and/or print templates depending on the institution/organization. For example, some organizations are required to send print notices for a fee/fine notice; whereas, some organizations have a no paper policy. For email, a subject, body (or multiple body parts) and signature are required. For sms, just a body of text is required. For print, they'll need to be able to include a patron name and address (for mailing) and body as well as signature.

It was suggested that contact information (and logo) being defined with location settings instead of in the notice itself. If it changes, then it is edited once, and it'll fix all notices.

Template requirements include:

  • Layout
  • Fonts, styles (perhaps somewhat limited though so accessibility regulations are considered)
  • Tokens or individual fields, such as patron name, fee/fine description and amount
  • Loop through multiple values, such as a list of all over items including multiple fields for each object (title and call number)
  • Conditional, such as if patron type equals faculty, then... or if patron type equals student, then...

Also, the idea of consolidating notices came up. The use case that came up is over items from multiple library locations. For some institutions, it's simple, one notice with all items overdue with one statement about fee/fine policies and/or contact information. For some, it's more complicated, they might each have their own policies and/or generated fees, so it look something like this:

Library 1
Statement about fee/fine policy and/or contact information
List of items

Library 2
Statement about fee/fine policy and/or contact information
List of items

...

Not sure what templating language will be selected but some early ideas include Mustache. Mustache seems to be popular because of it's simplicity and it's ability to integrate with several languages as described by this comparison chart - (https://en.wikipedia.org/wiki/Comparison_of_web_template_engines). I'd suggest it's biggest drawback is that it won't handle the conditionals outlined above. It will do a simple if exists/not empty test, but that's it.

For what it's worth, a few developers at Cornell have researched the topic of rich-text editors combined with templating languages for an email notification system, and their solution eventually became a combination of Quill (https://quilljs.com/) because it stores the template as JSON (and got them out of some earlier trouble with tags and/or elements being stripped out) and Liquid Droplets (https://github.com/Shopify/liquid/wiki/Introduction-to-Drops) for field tokens and/or code snippets. Or at least I think I'm explaining that correctly! Here's a ticket that goes into some details about their research - https://github.com/cul-it/studentsite/issues/862#issuecomment-349994330.



 Comments   
Comment by Cate Boerema (Inactive) [ 06/Sep/18 ]

Darcy Branchini I see this is still targeted for Q3 2018. Is there still a chance this can get into the release?

Comment by Cate Boerema (Inactive) [ 14/Sep/18 ]

This is blocked on endpoint for patron notice templates ( CIRCSTORE-68 Closed ) which is, in turn, blocked by these folijet stories: MODLOGIN-55 Closed and MODLOGIN-56 Closed

Comment by Cate Boerema (Inactive) [ 14/Sep/18 ]

Per agreement with Darcy, I am merging this with UXPROD-723 Closed . Given that, I have increased the estimates on this feature to include the time estimated for that feature.

Comment by Cate Boerema (Inactive) [ 26/Sep/18 ]

Darcy Branchini, this seems to be missing its frontend estimate.

Comment by Cate Boerema (Inactive) [ 28/Sep/18 ]

Michal Kuklis can you please estimate the front end work needed for this? Thanks much!

Comment by Michal Kuklis [ 28/Sep/18 ]

Cate Boerema done.

Comment by Darcy Branchini [ 28/Sep/18 ]

Jakub Skoczen - can you take another look at the back end estimate for this feature? Will it really be an XXL for just CRUD? The logic (scheduling, triggers - both event and conditions) is a separate issue.

Comment by Cate Boerema (Inactive) [ 18/Oct/18 ]

Matt Connolly, this feature has a 30 day backend estimate. I am pretty sure you said that the backend work was taken care of by Folijet so there is little to no BE work remaining for the Core team. Is that right? If so, can you please modify the backend estimate accordingly?

Comment by Cate Boerema (Inactive) [ 08/Nov/18 ]

Moving this from Blocked to InProgress because, as I understand it, CIRCSTORE-68 Closed (the remaining blocker) is redundant at this point. Development is unblocked.

Comment by Cate Boerema (Inactive) [ 11/Jan/19 ]

Hi Darcy Branchini. It is end of quarter and this feature is incomplete. It will need to be split:

  1. Tag this feature with split
  2. Create a new feature for the carry-over work and make a note at the top of the description that it was split out of this feature (this was requested by the early implementers)
  3. Make sure the rankings are not populated for the new feature (if you are starting by cloning this feature, you will have to clear them out). The early implementers wanted to rank all features including those that were split off from features they'd previously ranked.
  4. Move any incomplete stories out of this feature into the new one
  5. Mark this feature complete
  6. Make a note on the Weekly Status Report for Q4 about how this feature was split and why: https://folio-org.atlassian.net/wiki/display/PC/FOLIO+Q4+2018+Weekly+Status+Report
Generated at Fri Feb 09 00:09:34 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.