When we give the app developers more possible tasks in a process, including the ability to define what tasks are possible to move between, we need to show the end user using the app in altinn.no how to navigate between the tasks.
Ideas
Create classes to represent different parts of a process. Class for the process itself, classes for tasks, sequences, conditions etc.
Create a system for "running" generic tasks.
In scope
To what degree do we need / want to show the user how far in a process they have gotten?
How do we enable navigating to the next / previous task?
When/how do we allow navigating to/from the inbox (or other parts of SBL)?
Out of scope
This analysis should not define new possible tasks in a process - use tasks already identified at the start of the analysis as foundation.
Consideration
Return back to previous task
We need to use BPMN to design the process that supports a return to a previous task. In BPMN this is the current template with only "one way"
To support return the BPMN process need to add explicit flows for the return. The below diagram and BPMN file describe the above process with added return flow from Task 2 to Task 1. To implement
A common scenario is to skip tasks based on business rules. The following diagram shows a flow with a optional signing step. This is a common scenario where the business rule could be based on data in form. (example minimum sales amount)
If we use an exclusive gateway the next method could identify that there are multiple flows and trigger a new App interface method that the app developer controls. That method could then be populated with logic that decided what the next task is.
Task validation
The current behavior is to validate if a task can be ended. That includes validating if the required attachment is attached and all data models connected to the task are valid. But this is not relevant if you are going back in the process.
We need to update the code so when the process is going backward this validation is not required. The BPMN needs to define which flows that does not require validation. See suggestion in XML
Valid scenarios
We need to define what kind of scenarios Altinn Apps really want to support.
[ ] Go back from ConformationTask to previous data task? Suggestion Yes
[ ] Go back from SigningTask to previous data task? Suggestion Yes
The following flows would be invalid to set up in an Altinn Apps application
Go back to a signing task when signing has been completed
Go back from a data task
Go back passing a data task
Go back passing a signing task (reason: Signatures might be already downloaded and processed)
Go back passing a complete confirmation task (reason: Data might be already downloaded and processed)
Technical flows
Return to previous task
Technical flow when the instance is in Task 2 and user want to go back to Task1
Optional
In this process, the user does not dictate the next task, but the business logic decides based on the instance, possible the data and other aspects which task is next.
To support this we need a new method in App interface that let app developer build custom code to define which route from a gateway. Input to this needs to be instance and the process/gateway info.
In this way the logic can rely on the instanceValues or the data from the instance (using storage API)
Process navigation in frontend
The current views just expect that the only way to move in the process is forward. When there are multiple ways to go from a current task frontend needs to present the options to the users that they can go back to the defined
Frontend needs a way to get the Process options from current task. For that we need a new API that presented the current options, the title on that option and some indication which direction it is.
Task Authorization
We need to support the authorization of the user that chooses to move the process backward.
It is defined for each task type what is required to perform forward movement of process but it is not described what is required to backward.
Suggestion: User is authorized for Read at current task.
Default flows
We need to consider defining default flows if there are multiple flows out from a gateway. This to simplyfi API calls and to make it possible to trigger CompleteProcess.
See suggested example.
Coded Gateways.
Specification task
[ ] Define how a process flow can define that it is backward and does not need a valid current task to leave
[x] Update CanTaskBeEnded to support taking in next element and based on that identify that task does not need to be validated since it is a backward direction
[ ] Update
[ ] Create OnProcessTaskRevisit method that unlock data
[ ] Update RegisterEventWithEventsComponent to support publishing of revisitTask
[x] Update AuthorizeAction and calling code so it nows it is a "backward" movement
Alternative technical approach
In the current implementation, lots of business logic is located inside the process controller and the BMPN reader just for information about the process. The process is not responsible for doing any work.
Another approach is to introduce and ProcessEngine that is responsible for performing all business logic and trigger all other components that need to do work related to BPMN process.
See Altinn/altinn-studio#7067 for details
TBA
Analysis
Points discussed during a meeting Thursday 9. September:
Being able to navigate backwards in the process should require an explicit sequence flow going out of the current task and back to a earlier task in the process. It should not be possible to go back in a process if there are no such sequence flow declared in the BPMN.
It should already be possible to perform the "back" sequence by providing the id of the task the user want to go to as input to the "go next" API. The process "engine" will validate and ensure that it is valid by checking for a sequence flow.
One major hurdle is to unlock locked data elements. If the current task is a confirm "step", data elements have been locked, preventing any updates even if the process goes back to an earlier task. The data elements must bee opened again at some point.
Possible solutions:
Logic attached to a sequence flow performs the unlock. The logic could be triggered based on a naming convention of a sequence flow or a custom, Altinn specific, attribute on the sequence flow declaration.
Declaring a new type of task that can be automatically executed by the App. This is almost identical to the first suggestion. Instead of having the sequence flow point directly back to the earlier task it points to the automated "unlock task" which in turn points to the earlier process task. This is more complex, but we avoid attaching business logic to a sequence flow.
The issue here is the visual representation and added complexity for the app developer when working with the process. "Why do we need this weird task?" A tiny remedy could be to also have a separate task for locking, to pair up with unlocking.
We no longer lock the data elements when moving into a confirm task. Instead we prevent changes from being performed through authorization rules.
Instead of letting external systems (like the frontend) "navigate" the process by calling next, the decision making is moved to the process itself. The idea is that tasks declare themselves complete with some sort of end state and give control to the process that provides a new task (or end event) based on the situation.
The tricky bit here would be to provide the process the necessary information to determine what to do. Gateways can be coded and allowed access to instances that could be expanded with additional properties if needed. The logic could also get access to the data elements and even the actual data if needed.
Conclusion
TBD
Tasks
[ ] Is this issue labeled with a correct area label?
RonnyB71
commented
1 year ago
Description
When we give the app developers more possible tasks in a process, including the ability to define what tasks are possible to move between, we need to show the end user using the app in altinn.no how to navigate between the tasks.
Ideas
In scope
Out of scope
This analysis should not define new possible tasks in a process - use tasks already identified at the start of the analysis as foundation.
Consideration
Return back to previous task
We need to use BPMN to design the process that supports a return to a previous task. In BPMN this is the current template with only "one way"
To support return the BPMN process need to add explicit flows for the return. The below diagram and BPMN file describe the above process with added return flow from Task 2 to Task 1. To implement
Optional / conditional tasks
A common scenario is to skip tasks based on business rules. The following diagram shows a flow with a optional signing step. This is a common scenario where the business rule could be based on data in form. (example minimum sales amount)
If we use an exclusive gateway the next method could identify that there are multiple flows and trigger a new App interface method that the app developer controls. That method could then be populated with logic that decided what the next task is.
Task validation
The current behavior is to validate if a task can be ended. That includes validating if the required attachment is attached and all data models connected to the task are valid. But this is not relevant if you are going back in the process.
We need to update the code so when the process is going backward this validation is not required. The BPMN needs to define which flows that does not require validation. See suggestion in XML
Valid scenarios
We need to define what kind of scenarios Altinn Apps really want to support.
The following flows would be invalid to set up in an Altinn Apps application
Technical flows
Return to previous task
Technical flow when the instance is in Task 2 and user want to go back to Task1
Optional
In this process, the user does not dictate the next task, but the business logic decides based on the instance, possible the data and other aspects which task is next.
To support this we need a new method in App interface that let app developer build custom code to define which route from a gateway. Input to this needs to be instance and the process/gateway info.
In this way the logic can rely on the instanceValues or the data from the instance (using storage API)
Process navigation in frontend
The current views just expect that the only way to move in the process is forward. When there are multiple ways to go from a current task frontend needs to present the options to the users that they can go back to the defined
Frontend needs a way to get the Process options from current task. For that we need a new API that presented the current options, the title on that option and some indication which direction it is.
Task Authorization
We need to support the authorization of the user that chooses to move the process backward. It is defined for each task type what is required to perform forward movement of process but it is not described what is required to backward.
Suggestion: User is authorized for Read at current task.
Default flows
We need to consider defining default flows if there are multiple flows out from a gateway. This to simplyfi API calls and to make it possible to trigger CompleteProcess.
See suggested example.
Coded Gateways.
Specification task
Development task
Alternative technical approach
In the current implementation, lots of business logic is located inside the process controller and the BMPN reader just for information about the process. The process is not responsible for doing any work.
Another approach is to introduce and ProcessEngine that is responsible for performing all business logic and trigger all other components that need to do work related to BPMN process.
See Altinn/altinn-studio#7067 for details
TBA
Analysis
Points discussed during a meeting Thursday 9. September:
Conclusion
TBD
Tasks