6050b346a5
## Background Currently when a mode change sub mode is an ABORT/ALARM sub mode, operators must refer to an Excel spreadsheet matrix of which paper checklists to complete. This feature is part of an effort to further digitize work instructions and streamline the process of determining which checklists should be completed depending on the reason why a reactor alarmed / aborted. ## Description of Change NICA_ORDERS_SERVICES (and the NICA Integration Service) now support an order type "ABORT_ALARM", which may be triggered when a reactor mode change occurs and the sub mode contains "ABORT/ALARM". Whether or not a NICA order is created depends on if the NICA checklist defined in OpenInsight applies to that reactor type (EpiPro is excluded for now). The "flows" of checklists to prescribe are defined in the REACT_PROB_CAT records for the ABORT/ALARM sub modes. Furthermore, NICA checklists defined in OpenInsight can now feature a property of whether or not they should _not_ be re-prescribed if a new NICA order is created of the same type while one is already active. ## Testing - Local testing - UAT by Jonathon Sperling ## Notes In the previous NICA integration feature, Intrusive Maintenance, the MonA group resource name was stored in environment variables instead of in ENVIRONMENT_SERVICES. After further testing, this turned out to be an unviable option as environment variables that are picked up are from the user's client or the terminal server they are running OpenInsight from. Setting environment variables on all clients and the terminal servers is not practical, so this was removed in a previous PR. Related work items: #175188
Introduction
TODO: Give a short introduction of your project. Let this section explain the objectives or the motivation behind this project.
Getting Started
TODO: Guide users through getting your code up and running on their own system. In this section you can talk about:
- Installation process
- Software dependencies
- Latest releases
- API references
Build and Test
TODO: Describe and show how to build your code and run the tests.
Contribute
TODO: Explain how other users and developers can contribute to make your code better.
If you want to learn more about creating good readme files then refer the following guidelines. You can also seek inspiration from the below readme files: