The limit and incident statuses are determined by their workflows. When using a custom workflow, it’s likely that the
status values will differ from those provided in the default limit workflows.
We need to map these statuses to the actions that can be performed on the limit or incident so that Atoti Limits
is able to function using any custom statuses. This mapping can be configured using two different methods:
Using configuration properties
The following properties can be defined in your application.yml file to map custom workflow statuses to limit actions.
These properties are prefixed with limits.workflow.limit-workflow-action-statuses:
Property
Description
Default Values
inactive
Indicates the limit is no longer active, making it ineligible for consideration during the validation of new limits. Limit structures with only “inactive” limits will have their KPIs deleted.
DELETED, EXPIRED
evaluable
Indicates the limit is eligible for evaluation.
APPROVED
kpi-visible
Indicates the limit is still relevant to be viewed in KPIs, even if it’s only for historical analysis and is no longer active.
APPROVED, EXPIRED
pending
Indicates the limit was previously approved and is still active, but has been modified or requested for deletion and the modification/deletion has not yet taken effect.
PENDING, EDIT, PENDING_DELETION
Using ILimitsStatusManager
The ILimitStatusManager API provides methods to check if a limit has a status that is eligible for certain actions.
The default implementation of this interface is DefaultLimitsStatusManager, which checks the limit status against the
configuration properties mentioned above. If you don’t wish to use the configuration properties or need more complex
logic to determine the mapping, you can create a custom implementation of this interface and
expose it as a Spring bean to override the default
implementation.
ILimitsStatusManager
/**
* <b>ILimitsStatusManager</b>
*
* <p>This interface contains methods to check if a limit is eligible for certain actions based on
* its status. The value of the limit's status is determined by the workflow it is in, which may use
* custom statuses different from the ones in the default limit workflows.
*
* @author ActiveViam
*/publicinterfaceILimitsStatusManager{/**
* Checks if the limit is in an inactive state and should not be considered for things like
* evaluation or when validating other limits.
*
* @param limit the limit to check
* @return true if the limit can be created, false otherwise
*/booleanisLimitInactive(Limit limit);/**
* Checks if the limit is in a state that allows it to be evaluated.
*
* @param limit the limit to check
* @return true if the limit is eligible for evaluation, false otherwise
*/booleanisLimitEvaluable(Limit limit);/**
* Checks if the limit is in a state that allows it to be viewed in a KPI.
*
* @param limit the limit to check
* @return true if the limit is viewable in KPI, false otherwise
*/booleanisLimitKpiVisible(Limit limit);/**
* Checks if the limit is in a pending state, meaning it was previously approved, but has since
* been modified or deletion has been requested and is awaiting approval for the
* modification/deletion to take effect.
*
* @param limit the limit to check
* @return true if the limit is pending, false otherwise
*/booleanisLimitPending(Limit limit);}