Status locking mechanism
During parking and unparking, FormStore rules may trigger that would want to change the request status. There could then be 2 requests with the same number, but different statuses (e.g. PARKED and ABANDON). To prevent this, the status locking mechanism.
Locking status changes
Locking status changes occurs when a request is unparked. In special cases, also when parking. Then the value of the locking flag (unparked) is set to "true" (locked). It informs that any status changes should not happen. The request is then held in its current state.
Unlocking status changes
Unlocking status changes occurs when parking (including automatic parking) a request. In special cases, this happens only when it is "transferred". The locking flag (unparked) is set to "false" (unlocked). It informs that status changes are active.
Automatic unlocking of status changes
Automatic unlocking of status changes is needed in the event of a request getting stuck (e.g. due to a server failure). It is then checked whether the last modification of the request was at least 1 day earlier. If so, this is a reason to unlock status changes. This happens in two cases.
Activation of the unlocking rule
The rule goes through all requests with a locked status. If the unlocking condition is met, this request has its status changes unlocked.
Activation of state-changing rules
State-changing rules continue to process, as before, all requests that meet their conditions. At the moment when a request has a locked status but does not meet the requirements for automatic unlocking, the status remains unchanged.
If a request has a locked status but meets the automatic unlocking condition, or if the request has an unlocked status (standard behavior), the request is unlocked for status changes, and then the changes specified in the rule take place.
Locking flag
The locking flag is the "unparked" variable in the request metadata. Its state can be seen in FormStore in JSON (Figure 1) or in XML (Figure 2).
Last updated
Was this helpful?