Add support for uniqueFromSignaturesInDataTypes element for signature tasks

[standeren]

Description

In the config panel in process editor for signing tasks we need the possibility to specify if the signature's author has to be unique. That means that even though using different signature objects, there are cases where the signing actions in different tasks can have the same access rules connected to them, which means that the same person can sign all. This bpmn element (<altinn:uniqueFromSignaturesInDataTypes>) can be added to signing tasks that are added after the first signing task, in order to ensure that the same person cannot sign both tasks even though he/she has the correct access rights to do so.

The config in the bpmn file for the upcoming signing tasks will look like this:

<altinn:signatureConfig>
                <altinn:dataTypesToSign>
                    <altinn:dataType>Model</altinn:dataType>
                </altinn:dataTypesToSign>
                <altinn:signatureDataType>signatur2</altinn:signatureDataType>
                <altinn:uniqueFromSignaturesInDataTypes>
                    <altinn:dataType>[NAME_OF_SIGNATURE_DATA_TYPE_FROM_THE_FIRST_SIGNING_TASK]</altinn:dataType>
                </altinn:uniqueFromSignaturesInDataTypes>
            </altinn:signatureConfig>

NB: Having the option to make a signature for a task unique in should only be visible/enabled in signingtasks added after the first signing task. I.e. not the first signing task.

See docs for more information

Considerations/Questions

Should we do some check in the policy file wether the sign actions across signing tasks have the same roles connected to them and only show the option to make sure the signatures are made from different persons if so?

How to make sure we are in sync? I.e. if the app-developer changes the roles across the signing actions and making the uniqueFromSignaturesInDataTypes element in bpmn file unnecessary?

• Is it illegal config --> we must keep in sync some how
• or just noice? --> keep it

What if deleting the signing task that another signing task is referring to?

What if there are more than two signing tasks where all have the same access rights; should the app-dev be able to select which of the other signing-tasks that the current signature should be unique from?

How can we ensure what signing task is the first in the process and keep this in sync during editing?

Updates after clarification with Apps

• Referring to a signature datatype that has been deleted will not change behavior, but Studio should attempt to keep in sync by deleting the uniqueness element in the remaining signing task
• Consider make the uniqueness a default when adding subsequent signing tasks?
• We do not have to take the policy file into consideration. Let the user take an active choice even though the tasks have different access rights anyway. (Might be some weird cases where a user have multiple roles)

When a process with signatur tasks with this element is running in the apps, the apps code will only check if the current instance owner has written to the referred data type in the signing task -> if so, he/she cannot perform the signature, if not, he/she can sign. Meaning that referring to a signing task that is further behind in the process, will not have any effect. Studio should

• as a minimum inform the user about this in general
• or better, inform the suer about this if he/she puts the process in state where that is the case
• or the best, always validate the process and check that all references make sense

Design-wise:

• either display a switch that makes the signing-task unique from all other signing-tasks, but then we need to update tasks that are not explicitly changed by the app-developer behind the scene.
• display checkboxes for all the other signature tasks (preferably only the subsequent) and add/remove the connected signature data type to the ones that are being checked.

Design

Probably enough with a switch and some information about what this action will mean for a running app. But need to check with team Apps if there should be possible to select what signing task to refer to (which will connect the name of signature object to that task to the current task behind the scene).

Also need to consider when this config should be visible and how validation messages should act/be. Also need to check with team Apps how strict the config is.