Page History
...
| Issue | Background information | Severity |
|---|---|---|
| Maintenance-App restore endpoints could lead to cases getting stuck | The maintenance user has several endpoints to restore errors on a case. However, endpoints sometimes work only when the case is in a specific state. For example, the "reopen task" endpoint only works when the case is still locked, so when the lock has been deleted by another restore endpoint, the case cannot be restored ever. We need to make sure restore endpoints can only be applied when they could fix the case, instead of breaking the case. Examples:
A different approach would be to include all actions, so the "unlock case" endpoint would cancel any started tasks, making it a bit less evident what the endpoint is really doing. | medium |
Multi-valued attributes and relations cannot be used in the DCM_GetCaseInfo. | In the new set-up, the service call is actually a REST call from the Runtime to the Case engine. Therefore, an interface (in JSON) is needed. Since we cannot just add complex graphs and all kinds of (multi-valued) attributes, they will be ignored for now | low |
| Testpaths do not work on timed events or automatic tasks | Testpaths are session bound, and will be lost when a new session is started. In the new setup, all automatic tasks and timers will be evaluated and executed in their own session (asynchronous), therefore the testpath will not be available. Testing a DCM application will be a new business case to do further research on what is needed, and how this can be achieved. | low |
| Priority Algorithms don't work | Priority algorithms are based on the addition of custom code to evaluate priorities at certain moments in time. The Case Engine does not allow custom code. The task field A new business case will be added to the product management backlog to investigate the requirements for case and task prioritization. As an alternative, priority can be modeled and managed as a custom field for a task. | low |
Overview
Content Tools