currently the CallActivity configuration options include selections for passing all process variables to and from the main process.
We have some user-tasks in which some of the process variables should not be read/written by the assignee. Would it be possible to add call-activity style ‘pass-all’ options to the existing input/output mappings of tasks?
I’m not quite sure I understand the use case. You wrote
What does ‘pass-all’ variables then mean for this context? As it seems you want to hide variables or at least make them read-only. Can you elaborate on this?
an user-task with no read access to existing variables (simple receipt task),
an user-task with no write access to new or existing variables
My understanding is that empty Input/Output mappings now means that all values are read/written between process and task scopes, and that when fields not defined in forms are submitted, they end up in as variables in the task scope and hence are copied to the the process. The CallActivity extension elements however define
so you want to achieve that the variables in the task scope are local copies of all process variables. And without an output mapping changed local task variables will be removed. Do I understand you correctly?
But this would not solve any of your use cases? There would still be read access to the variables and how do you prevent write access to the variables with a pass-all mapping? Sorry if I misunderstood you.
hmm so let me put this another way: I want to limit / explicitly define (in form and/or Input mapping) what variables are copied to task scope. And as an additional option, I’d like to be able to explicitly bypass this constraint by saying that all variables should be copied (preserving current functionality when a positive).
Correspondingly, a variable set on the task scope which has no output mapping or form field, should not be copied to process scope unless this constraint is explicitly bypassed.
This implies that if a form is completed with an additional variable value, it is refused. See the test-case FormDataTest.testFormFieldSubmit() - adding random variables to the map used in formService.submitTaskForm(…) does not result in errors. So you can add a ‘require’ constraint on a form field, however not a corresponding ‘no additional values required’ constraint on the form itself.
Another angle: See class DefaultFormHandler method submitFormVariables(…):
// any variables passed in which are not handled by form-fields or form
// properties are added to the process as variables
for (String propertyId: propertiesCopy.keySet()) {
variableScope.setVariable(propertyId, propertiesCopy.getValueTyped(propertyId));
}
I’d like an option which adds an if statement around the above code.
@skjolber did you come up with any solution to this. Looking at a similar issue.
To make sure I understand your issue and ensure it is similar to my question, you are asking:
How can you restrict which variables are accessible and modifiable (at a process level and task level)? The scenario being that someone could inject additional variables or modify existing variables, and you want to restrict this?
You have a embedded form, and the current implementation is setup in a way where if the user has access to the process they can read and write to all process variables.
The desired scenario would be that in the task configuration you could choose which variables you want to exposed (read) and which variables you will accept (allow edits/submissions) of.
So it would create scenarios where if someone modified the rendered form to submit or read a process variable that was not exposed for that task, the user would not have access.
If i understand the docs, at the moment there is a high level of trust with all users in task list. If you are a user, then you can change a lot of variables if you desired.
This scenario is not possible in the current Camunda setup? Another system is required to manage the permissions around what can and cannot be modified?
Implemented a custom submit endpoint which pulled the form fields from the task and checked against the submitted fields for write access. For reading, we exposed at the form field default values and the input/output mappings.
This all was part of a setup where we made a generic ‘human task’ REST service for taking a user through a number of human tasks within a single process instance.
No, unfortunately, I have moved on and no longer have access to the code.
I’ve been thinking about creating some kind of ‘process driver’ which lets a user (i.e. webapp) relate to a single process at a time, with async signalling. The tasklist did really not fit very well for that purpose.