Skip to end of banner
Go to start of banner

Order Alerts

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Current »

Overview

Alerts serve as a way for the system to bring attention to issues that require human intervention.  The context here is orders.  See the linked feature for additional background and use cases.

NOTE: While the orders schemas already have some notion of alerts, they're not being used - At least they're not exposed by the UI and aren't being populated by FOLIO.  This is an artifact from the very early days of acquisitions.  

Approach

  • Introduce a new controlled vocabulary 'AlertType'
    • new schema
    • new storage (CRUD) API
    • new business logic (CRUD) API - proxies to storage API
  • Refactor po-line alerts
    • to reference an AlertType
    • have a single free-form text field for capturing context/error information
    • system generated metadata
  • Add new field to composite_purchase_order
    • numAlerts
      • integer
      • default 0
      • derived property - not stored.
  • Update GET /orders/composite-order/<id>
    • calculate numAlerts

Schemas

alert_type

Property

Type

Default

Required

Notes

id
string
NANo

UUID of the AlertType - generated by the system if not provided

namestringNAYesA name for the alert type, e.g. "Failed to open",
descriptionstringNANoAn optional description of the alert type
metadatametadataNANoSystem generated metadata

alert

Property

Type

Default

Required

Notes

id
string
NANo

UUID of the AlertType - generated by the system if not provided

alertTypeIdstringNAYesUUID of an alert type 
contextstringNAYesFree form text providing additional context, e.g. an error message
metadatametadataNANoSystem generated metadata

APIs

mod-orders

Interface

Method

Path

Request

Response

Description

Notes

alert-typesPOST/alert-typesalert_typealert_type

Create an alertType

Proxy to storage module.  
alert-typesGET/alert-typesCQL Querycollection<alert_type>List/search alertTypesProxy to storage module.  
alert-typesGET/alert-types/<id>NAalert_typeGet a particular alertTypeProxy to storage module.  
alert-typesPUT/alert-types/<id>alert_type204Update an alertType Proxy to storage module.  
alert-typesDELETE/alert-types/<id>NA204Delete an alertTypeProxy to storage module.  

mod-orders-storage

Interface

Method

Path

Request

Response

Description

Notes

order-storage.alert-typesPOST/order-storage/alert-typesalert_typealert_type

Create an alertType


order-storage.alert-typesGET/order-storage/alert-typesCQL Querycollection<alert_type>List/search alertTypes
order-storage.alert-typesGET/order-storage/alert-types/<id>NAalert_typeGet a particular alertType
order-storage.alert-typesPUT/order-storage/alert-types/<id>alert_type204Update an alertType 
order-storage.alert-typesDELETE/order-storage/alert-types/<id>NA204Delete an alertType

User Interface

Several requirements related to this work necessitate some UI work:

  • ability to filter - give me orders and lines w/ alerts
    • Populate filter based on:  GET /alert-types?limit=N 
    • GET /orders/composite-orders?query=cql.allRecords=1 NOT alerts ==/respectAccents []
    • GET /orders/order-lines?query=cql.allRecords=1 NOT alerts ==/respectAccents []
    • NOTE:  These queries may change once the order/order-line views are replaced with foreign keys and cross-index subqueries
  • ability to see in order search results that there are N alerts
    • use composite_purchase_order.numAlerts
  • ability to see in order-line search results that there are N alerts
    • use length of alerts array
  • ability to add one or more alerts to a poLine
  • ability to remove an alert - eventually the ability to mark as resolved

Mock up to be provided by Dennis Bridges

JIRA


  • No labels