Backend - Request-related notices added to a notice policy

Context
Library staff (administrators) need to be able to setup and configure notice policies to define triggering events and conditions and utilize notice templates (UICIRC-86, UICIRC-85, UICIRC-87) for requests.

User Story
Requests for an item can be described as:

• If the item is already checked-out by another patron, then a hold or a recall request is initiated.
  • A hold means the patron that currently has the item checked-out cannot renew the item.
  • A recall means the patron that currently has the item checked-out must return the item earlier than originally anticipated.
• If the item is available (and not checked-out by another patron), then a paging request is initiated.

This story is intended to add request-related notices to notice policies. Basic notice policy CRUD has already been designed (and are in development). Please see UICIRC-98 (new/edit), UICIRC-108 (view), UICIRC-109 (delete), and UICIRC-106 (single notice for new/edit). In the future, we'll be adding fee/fine-related notices (for aged to lost and overdue) to notice policies. Since the stories mentioned above already cover notice policy CRUD, this story is specific to adding request-related setting to a notice policy.

Examples of request related notices include confirmation of request, availability of request (for pick-up), hold reminder, hold expiration and/or staff cancellation.

Scenario 1 - Edit
Given Settings > Circulation > Notice policies > Select specific notice policy
Allow library staff (FOLIO administrator) to edit an existing notice policy
Display policy in edit mode as full screen using accepted design pattern (see UICIRC-98) with the additional request-related settings

• Request notices as an accordion section (below Loan-related notices accordion). If open, displays each notice within a separate box with form input/select labels and current values:
  • Each notice is displayed in a separate box and should follow same pattern as Users > Addresses. See Scenario 3 (below) plus UICIRC-106 for specific fields and their dependencies.
  • If closed, caret in down position, nothing else shown.
  • If open, caret in up position with
    • "Add Notice" as default button at bottom of section, below other notices
      • If "Add Notice" is clicked, a new notice box is added at the bottom of this section (after other notices defined)
  • Each notice defined is displayed in a separate box with form input/select labels and current values

Scenario 2 - New
Given Settings > Circulation > Notice policies > New notice policy
Allow library staff (FOLIO administrator) to create a new notice policy
Display policy in edit mode as full screen using accepted design pattern (see UICIRC-98) with the additional request-related settings with

• Request-related notices as an accordion section (below Loan-related notices accordion). If open, displays each notice within a separate box with form input/select labels and current values:
  • Each notice is displayed in a separate box and should follow same pattern as Users > Addresses. See Scenario 3 (below) plus UICIRC-106 for specific fields and their dependencies.
  • If closed, caret in down position, nothing else shown.
  • If open, caret in up position with
    • "Add Notice" as default button at bottom of section, below other notices
      • If "Add Notice" is clicked, a new notice box is added at the bottom of this section (after other notices defined)
  • Each notice defined is displayed in a separate box with form input/select labels and current values

Scenario 3
Given a notice policy
Allow library staff (FOLIO administrator) to define a single notice within this policy
Display

• Notice count at top left
• Delete icon (trash can) at top right. If clicked, delete notice.
• Possible fields:
  • Template on first line
    • Required select with options populated from patron notice template names with a category of Request
  • copy "via" on first line (plain text)
  • Format on first line
    • Required select with options populated from patron notice templates general settings > format, possible options include:
      • Email
      • Email is the only option for first release; other options, including SMS and print, will be developed at a later date.
  • Frequency on first line
    • Required select with options:
      • One time
      • Recurring
  • Send Event or Starting Send Event on second line
    • Required select with options:
      • Upon/At
      • Before
      • After
    • Required select. Specific options are determined by category/section. For request notices, select should contain the following options:
      • Recall request
      • Hold request
      • Paging request
      • Available
      • Hold expiration
      • Request cancellation
    • If Before or After is selected (above)
      • copy "by" (plain text)
      • Required number input (1 through 100 are valid numbers) and placeholder of 1 (NOT select)
      • Required select with the following options:
        • Minute(s)
        • Hour(s)
        • Day(s)
        • Week(s)
        • Month(s)
        • Year(s)
    • If Recurring is selected (above)
      • Send Every on third line
        • Required number input (1 through 100 are valid numbers) and placeholder of 1 (NOT select)
        • Required select with the following options:
          • Minute(s)
          • Hour(s)
          • Day(s)
          • Week(s)
          • Month(s)
          • Year(s)
  • Send in real-time
  • Checkbox

PLEASE NOTE: All required fields should have an asterisk next to their label.
How does it know which patron to send the notice to? For example, if a recall is initiated, an institution may want to send to a confirmation of the recall to Patron B and a recall notice (with the new earlier due date/time) to Patron A.

All mockups related to CRUD patron notice policy are available here - https://drive.google.com/drive/folders/1usWSfAebfPn6Z7CZE1Vya2gXnmKl3NTg.

Backend work: change the patron-notice-policy schema extending list of options for field 'requestNotices.sendOptions.sendWhen'. New valid options should be:

• Recall request
• Hold request
• Paging request
• Available
• Hold expiration
• Request cancellation