Candidate Groups don't get migrated

Camunda 7 Topics Discussion & Questions
1

Some time ago we started using the MigrationPlan within our application to handle migrations automatically. This worked fine up until today when we discovered an issue and we were wondering if this is by-design or a bug. In short: if you update a candidate group, existing tasks don’t get the new candidate group but keep the old one.

Lets say in process V1 we have a task: Compose Letter. This task has a candidate group: ‘writer’. Now we want to release process V2. In V2 we still have the task ‘Compose Letter’ but we have changed the candidate group to ‘editors’. The migration using the MigrationPlan goes fine but after the migration, the ‘Compose Letter’ tasks that were started on V1 (but are on V2 now) still have the old candidate group, namely ‘writer’ and aren’t migrated to use the new ‘editors’ group. Is this by design?

Kind regards,

Bob

Edit: We use camunda-bpm-spring-boot-starter-bom v2.2.0.

1 Like
2

Hi Bob,

This is expected behavior, see https://docs.camunda.org/manual/7.9/user-guide/process-engine/process-instance-migration/#user-task. I can see use cases for both and I could imagine a configuration option like for events (https://docs.camunda.org/manual/7.9/user-guide/process-engine/process-instance-migration/#events).

Cheers,
Thorben

1 Like
3

Hi Thorben,

Thanks for the quick response. It would be nice to have this functionality available as a configuration option but for now we will just have to be careful while doing migrations.

  • Bob
4

Hi, thanks for asking / answering, that helped me avoid a wild goose chase today :slight_smile:

I’m having a similar problem right now.

Migrating this kind of data seems quite complex (I’m digging deep into the Database model currently).

Would be great if there was a “shortcut”, like some prepared scripts or a software utility… Is there anything like that anywhere, yet?
Or, is there an easy way to re-initialize the UserTask:s?