Hello, I have a question. After a service action, I have a regular action where certain fields should be set to “read-only.” I’ve configured it in the Camunda form to make the fields “read-only,” but during execution, I notice that the fields can still be changed, even though they are set to “read-only.” Did I do something wrong? Thank you for your help.
Hello my brother!
Did you mean that when creating your form, you placed some fields as read-only, and even so, when accessing your tasklist, the field can be modified… is that it?
Is there any script in your process that could be programmatically changing this?
William Robert Alves
I mean exactly that. Before, I have a service action, and in my code, I have a map where the key of the field for the next action is stored along with its corresponding values. Unfortunately, in the next action, all fields can be modified. I have 4 fields, and one field is changed in the service action. Even though nothing happens to the other 3 fields, all 4 fields can still be modified, even though they are set to ‘read-only’?
Can you show us your BPMN file with a more detailed explanation and this part of your code so I can check it better?
William Robert Alves
Unfortunately, the issue also occurs with other processes. I tested it on a process that receives two actions. In the first action, you write something, and in the last action, the value should appear, and you’re not supposed to be able to make any changes. However, you can still edit the field even though it’s set to ‘read-only.’ I asked a question about this yesterday, but it was removed, even though it could be helpful for other users. I tested the process in ‘play mode,’ and it immediately recognized the field as ‘read-only,’ and you couldn’t make any changes. The problem is pervasive and not limited to service actions. I’m not sure what to do now.
Hi @anon64962691 - this is likely because your cluster hasn’t been upgraded to 8.3 yet. In Modeler, in the bottom right of the window, there is a Zeebe version to validate your form or process against. If you select 8.3, it will validate; if you select 8.2 or lower, you will get errors in the “Problems” output like this:
Try updating your cluster to 8.3 and see how it works!
It works, but I used Camunda 8.2 back then, and the form had everything set up for 8.2. I could set whether the field is read-only or disabled. So, two weeks ago, it worked, and I wanted to ask if I can continue to use the Camunda form, but it’s on 8.2 and not 8.3.
It’s possible that Modeler was set to use an alpha version of 8.3, so the forms validated correctly against the engine. However, Tasklist would not have been able to render the field as read-only before the 8.3 release (and before updating your cluster(s) to 8.3). Maybe some confusion with disabled?
It seems that you’re discussing a specific configuration related to Camunda version 8.2, and you’re trying to understand how certain fields were set to “read only” instead of “disabled.” Here’s the English translation of your message:
"I’m sure that back then, I was using the stable version for my cluster with Camunda 8.2. At that time, it worked, and the fields that I set to ‘read only’ in Camunda Forms in version 8.2 appeared gray. I’m certain I didn’t use ‘disabled.’
{
“executionPlatform”: “Camunda Cloud”,
“executionPlatformVersion”: “8.2.0”,
“exporter”: {
“name”: “Camunda Web Modeler”,
“version”: “c6c1efb”
},
“schemaVersion”: 11,
“components”: [
{
“text”: “# Task A”,
“label”: “Text view”,
“type”: “text”,
“layout”: {
“row”: “Row_1td4l1u”,
“columns”: null
},
“id”: “Field_0xris5o”
},
{
“label”: “Name”,
“type”: “textfield”,
“layout”: {
“row”: “Row_0j7uyvx”,
“columns”: null
},
“id”: “Field_0t9s721”,
“key”: “field_Name”,
“readonly”: true
}
}
Back then, it worked during execution. I’m somewhat confused now. How were these fields set to ‘read only’ in version 8.2
The read-only feature did not exist until 8.3, so it is impossible for Tasklist to have rendered a read-only form field prior to 8.3.
However, because we release alpha previews of upcoming releases, that means that Modeler supports validation for future engine versions. If Modeler targeted engine version was accidentally set to an 8.3 alpha release, it likely would not have displayed any errors.
So it is possible for your form definition to have the read-only property, but it’s impossible for Tasklist to render it as read-only prior to 8.3. It’s hard to say what you were seeing before, unfortunately.
I understand. Thank you. It’s kind of strange, but that doesn’t matter. If I understand correctly, I should use Engine 8.3 instead of 8.2 when the fields should be read-only. Is that right?
Correct. The alternative in previous versions is the disabled property.
Thank you. What is the difference between ‘read only’ and ‘disabled’? I have only read that with ‘disabled,’ the data is not passed on or something like that.
I believe you are correct: a disabled field does not send the variable/data back to the process, but a read-only field does.
Thank you. When I tested Camunda 8.2 back then, and the fields were disabled, the values of the fields from the last action could still appear.