Description
In a model, if I update only the things related to a form (json schema etc) it'll not recognize that as an update for the migration.
I changed few things in the json schema for this user task and then I tried to migrate it.
It says 'The process instance is already associated with the most recent process model version.'
Test model : https://timetracking.spiffworkflow.org/process-models/misc:qa:madhu-testing:simple-form-1
json schema forms are not part of the spiff serialization. as a result, if you start a process instance and then change a form json schema, you will not be allowed to migrate the instance to the new form definition (since the system does not see that there is any change that would warrant a migration). to mitigate this, we propose:
- new database table with git_revision, form_schema_hash, and actual form schema contents, and maybe the process model identifier where the json files live to tie it back.
- populate this table at process definition creation time
- when we serialize process instances, include the form_schema_hash on each user task (assuming there is a linked form), using the combined 3 in 1 json as specified in Support attaching forms to message start events like we do with user tasks bpmn-js-spiffworkflow#77
consider how to bring existing environments into alignment with the new approach.
we were thinking about adding a table, form_schema, to link up git revisions, form hashes, form filenames, and process model identifiers with their corresponding form contents. we know we need to get something into the serialization in order for the user task form definition to work seamlessly for process instance migration, so we also started writing a Custom converter for user tasks with some guidance from Elizabeth. we got hung up because actually getting the form schema hash turns out to be not at all straightforward. from inside the converter, we could figure out what process model the task spec is in, potentially, and do the filesystem and json operations to determine the hash, but this seems slow and potentially outside the scope of what a to_dict function is generally supposed to do. since this is not something that obviously affects myome, we'll set it aside for now.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status