richard-churchman
5f6bbe45f7
Major bug fixes relating to the Redis implementation in Reprocessing and Search Key Cache were identified and fixed as part of the rekeying development. Included functionality to stop the Exhaustive training. Fixed the Unsupervised learning functionality in Exhaustive Training. Embedded the Mock Data CSV data into a class to make it compatible with Docker without needing to modify the Dockerfile (i.e, build). Included a new table that stores training data to enhance support capabilities for Exhaustive. Reintroduced and validated the Multitenancy functionality. Postgres is now fully deprecated in place of Redis for cache, and all implementations of the Interfaces for Postgres have been removed. No migrations exist to support this deprecation, and Postgres as a cache is now wholly unsupported. Removed the Indexing background thread, as Redis does not require it, given that it is a key-value pair database. Created a RedisCommandFlag Environment Variable to support Fire and Forget write to Redis in Invocation. Implemented functionality to Export, Peek and Download configuration environments using a secure, encrypted scheme. Created a permission to access the functionality via the user interface. Extensive database-based logging is included to provide for a comprehensive audit. Created functionality to Import the encrypted Export file inside a database transaction to ensure consistency. As Docker is now the primary deployment model, log4net instantiation has been moved to an approach that primarily uses programmatic instantiation of the ConsoleLogger and RollingFileAppender given Environment Variables. Implemented functionality to support remote \ mounted Log4Net XML Serialisation files for more advanced log4net configurations. Reintroduced access to counters via the user interface and created a permission. Took the opportunity to implement ReSharper linter suggestions. Disabled the Lock button across the whole application, with that functionality being reserved for future use. It is intended that locking happens programmatically on the basis of dependencies in future commits. Fixed several significant end-use bugs which became apparent during testing of the refactored code relating to case management and visualisations. Fixed certain other minor bugs that came up during testing. Brought documentation up to date for this commit. Brought the Docker Compose file up to date for this commit. Removed Redundant Environment Variables for this commit. Made the README file less verbose and unnecessary.
4.0 KiB
layout, title, nav_order, parent, grand_parent
| layout | title | nav_order | parent | grand_parent |
|---|---|---|---|---|
| default | Cases Workflow Status | 2 | Case Management | Configuration |
🚀Speed up implementation with hands-on, face-to-face training from the developer.
Cases Workflow Status
When a case is created, it can be allocated a status, which is helpful for filtering. Furthermore, when a case is being worked, changing the status allows for the sub allocation of the record (for example to a money laundering officer for review). Statuses are separate from the closed status (i.e. Open, Closed etc).
A common example for case status use is to escalate cases through a hierarchy in an money laundering team, such as:
- Front Line Defence (FLD).
- Deputy Anti Money Laundering Compliance Officer (DAMLCO).
- Anti Money Laundering Compliance Officer (AMLCO).
To begin the addition of Cases Workflow Status, navigate to Administration >> Models >> Cases Workflows >> Cases Workflow Status:
Cases Workflows Status is a child of Cases Workflows, itself a Child of Models. It follows that the tree to administer models and cases workflows is now of three levels deep.
It is incumbent to expand upon the model to reveal the Cases Workflows entry:
Exposing the newly created Cases Workflow, which can be used to create new children of the Cases Workflow:
Click on the Case Workflow entry to begin the process of adding Case Workflow Status:
The parameters are as follows:
| Value | Description | Example |
|---|---|---|
| Priority | The priority of the workflow flow entry. A status can be upwardly classified, such that if a case record already exists, the priority can be raised for that record, yet the priority of a case record may never decrease. | High |
| Status Fore Colour | The colour of the text for this status. The colour is used in the main bar on the status page. | #0000FF |
| Status Back Colour | The colour of the background for this status, the colour is the main bar on the status page. | #880808 |
Notifications and HTTP Endpoint as common among the following section of Cases Workflow configuration, are documented separately and not covered in detail in this section, being common in several sections of the Cases Workflows configuration such as:
- Cases Workflow Form.
- Cases Workflow Action.
- Cases Workflow Macro.
Complete the page as described above and as below:
Scroll down the page and click the Add button to create a version of the Cases Workflow:
The Cases Workflow Status are available for allocation on case creation or by the end user while navigating the case.
For confirmatory purposes, navigate to the Activation Rule definition for Volume1DayUSDForIPOver100 in the main menu, expand using the Cases switch, and select the newly created Cases Workflow:
It can be seen that the newly created Cases Workflow Status is now available as a child of the newly created Cases Workflows.
At this stage, no case record has been created, but Cases Workflow Status are available for filtering via the Cases Workflow filter, described separately.