Uploaded image for project: 'UX Product'
  1. UX Product
  2. UXPROD-675

CRUD patron notice templates

    XMLWordPrintable

Details

    • Large < 10 days
    • XL < 15 days
    • Very Small (VS) < 1day
    • Hide
      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.

      Show
      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.
    • Prokopovych
    • R1
    • R1
    • R1
    • R1
    • R1
    • R1
    • R1
    • R1
    • 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 for more details on templates.

      Details on Templates (UXPROD-723 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.

      TestRail: Results

        Attachments

          Issue Links

            Activity

              People

                dbranchini Darcy Branchini
                dbranchini Darcy Branchini
                Darcy Branchini Darcy Branchini
                Michal Kuklis Michal Kuklis
                Jakub Skoczen Jakub Skoczen
                Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved:

                  TestRail: Runs

                    TestRail: Cases