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
Schemas
alert_type
Property | Type | Default | Required | Notes |
|---|---|---|---|---|
id | string | NA | No | UUID of the AlertType - generated by the system if not provided |
| name | string | NA | Yes | A name for the alert type, e.g. "Failed to open", |
| description | string | NA | No | An optional description of the alert type |
| metadata | metadata | NA | No | System generated metadata |
alert
Property | Type | Default | Required | Notes |
|---|---|---|---|---|
id | string | NA | No | UUID of the AlertType - generated by the system if not provided |
| alertTypeId | string | NA | Yes | UUID of an alert type |
| context | string | NA | Yes | Free form text providing additional context, e.g. an error message |
| metadata | metadata | NA | No | System generated metadata |
APIs
mod-orders
Interface | Method | Path | Request | Response | Description | Notes |
|---|---|---|---|---|---|---|
| alert-types | POST | /alert-types | alert_type | alert_type | Create an alertType | Proxy to storage module. |
| alert-types | GET | /alert-types | CQL Query | collection<alert_type> | List/search alertTypes | Proxy to storage module. |
| alert-types | GET | /alert-types/<id> | NA | alert_type | Get a particular alertType | Proxy to storage module. |
| alert-types | PUT | /alert-types/<id> | alert_type | 204 | Update an alertType | Proxy to storage module. |
| alert-types | DELETE | /alert-types/<id> | NA | 204 | Delete an alertType | Proxy to storage module. |
mod-orders-storage
Interface | Method | Path | Request | Response | Description | Notes |
|---|---|---|---|---|---|---|
| order-storage.alert-types | POST | /order-storage/alert-types | alert_type | alert_type | Create an alertType | |
| order-storage.alert-types | GET | /order-storage/alert-types | CQL Query | collection<alert_type> | List/search alertTypes | |
| order-storage.alert-types | GET | /order-storage/alert-types/<id> | NA | alert_type | Get a particular alertType | |
| order-storage.alert-types | PUT | /order-storage/alert-types/<id> | alert_type | 204 | Update an alertType | |
| order-storage.alert-types | DELETE | /order-storage/alert-types/<id> | NA | 204 | Delete an alertType |
JIRA
Feature: UXPROD-2327 - Getting issue details... STATUS
Stories:
- TBD
NOTES:
Alerts:
- AlertType = controlled vocabulary - with system values that are always there (e.g. for "Order failed to open") - need to define these!
- Context/Error/Alert text = free form text
- Metadata = system generated
Also needed:
- ability to filter - give me orders and lines w/ alerts
- ability to see in order search results that there are N alerts
- ability to remove an alert - eventually the ability to mark as resolved
Stories:
- MODORDERS-176 - do as is
- Create stories to implement what we have above
- Create another story to update various places in order logic to create alerts (e.g. at least the MODORDERS-176)