Hi all,
we are updating from Camunda 7.9 to 7.13 (Spring Boot version). We noticed that there has been a modification:
Can anyone give us a hint how to achieve the same effect in version 7.13? Is there a configuration for that?
Thank you in advance,
Vendel
Are you following the migration docs?
Is there a specific point where this problem shows up?
Hi @Niall,
yes, we are following the migration docs, in particular:
Reg. user-operations we found the following:
Although it relates only to READ / DELETE permissions for user operation log entries, we added new permission as described in the docs (it didn’t solved the problem).
The specific problem we faced to:
A process instance is waiting in a user task. There is a boundary message event on it, which is caught (activated) by a user-authenticated request to the POST engine-rest/message endpoint:
This produced earlier in Camunda 7.9 user operation entries in ACT_HI_OP_LOG, while in Camunda 7.13 there is no entry in the db. The process-flow works as expected, the only missing thing is the lack of entries (which are needed for history-views later).
Any idea?
Vendel
Hi @vendel.saghy,
In case you can, please provide an example that reproduces the scenario, that will speed up the investigation of the issue.
Please consider sharing a simple spring boot starter in github. Also you can use one of the template projects:
Hi @Yana
I’ve prepared two sample repo’s (both are very-very small, containing only the relevant part) :
Camunda Version 7.9: https://gitlab.com/vendel.saghy/camunda-spring-boot-79
Camunda Version 7.13: https://gitlab.com/vendel.saghy/camunda-spring-boot-713
Both projects are Camunda Spring Boot projects. Please follow the Readme.md. Both projects contain the same (very small) bpmn-process.
There are in both repo’s Postman environment and collection files (see Readme.md). There is a POST message request in the collection (3_POST_message):
If you run the requests 1_start_process, 2_GET_Task and 3_POST_message sequential, you’ll recognise after step 3 (POST message) the following:
• in Version 7.9, there is an entry with operation_type_ = delete in the table HI_OP_LOG --> that’s the expected behaviour for me.
• in Version 7.13 there is NO entry with operation_type_ = delete --> this is the record in the table, which I miss. (side effect: in 7.13 there is a new entry with operation_type_ = create, which we didn’t have in 7.9 --> that’s another difference between the versions, but this is not a problem for our case).
What I would like to achieve:
An entry in HI_OP_LOG with operation_type = delete as a result of the request POST engine-rest/message, without additional (new) listener or custom history-implementation.
Do you have any idea, how would it be possible?
Thank you, Vendel
Hi Vendel,
Thanks for the provided examples.
The user operation log that is stored in 7.9 is delete task entity:
| OPERATION_TYPE_ | ENTITY_TYPE_ | PROPERTY_ |
|---|---|---|
| Delete | Task | delete |
By design the log should not be stored during sending message that cancels the user task. Meaning the operation that your perform is not deleting a task, the deletion is only a consequence of the initial operation - sending a message. The user operation log for delete task should be logged only if the user performs a delete operation directly. So the observed behavior in 7.9 is incorrect which we fixed with CAM-10962 implemented on 7.12. That’s why the difference in the behavior in 7.13, the issue from 7.9 is fixed there.
In case you relayed on the incorrect behavior in 7.9, please adjust your implementation.
I hope that helps.
Best regards,
Yana
Thank you @Yana!