* return the process instance when interstitial process is complete and favor redirecting to it on the frontend
* upgrade certifi for snyk check
---------
Co-authored-by: jasquat <jasquat@users.noreply.github.com>
* return the process instance early from the interstitial if it is suspended or terminated
* added a test to make sure the interstitial page returns the process instance if suspended or termianted w/ burnettk
* randomize tests and cleaned up the pyproject file a little bit w/ burnettk
---------
Co-authored-by: jasquat <jasquat@users.noreply.github.com>
* move data migration code out of bin so it can be reused in background processor
* sleep for 5 minutes and update bpmn js to pull in some fixes from elizabeth
* update spiff to pull in parser update to make it act like before
---------
Co-authored-by: burnettk <burnettk@users.noreply.github.com>
* some initial changes for event payload changes in spiff
* fixed tests for new spiffworkflow with event payloads w/ burnettk essweine
* pyl w/ burnettk essweine
* updated SpiffWorkflow from branch
* switched SpiffWorkflow back to main w/ burnettk
* added base for migration script to upgrade db w/ burnettk essweine
* some updates to script w/ burnettk
* script has been written, needs to be tested
* pyl w/ burnettk
* updates to migration script so it can work w/ burnettk
* pyl w/ burnettk
* added comment to data migration file
* run the version 1 3 migration on app boot w/ burnettk
---------
Co-authored-by: jasquat <jasquat@users.noreply.github.com>
* also check human task table for completed by user when determining if an instance is associated with a user
* update pygments
* added some comments for clarity w/ burnettk
---------
Co-authored-by: jasquat <jasquat@users.noreply.github.com>
Co-authored-by: burnettk <burnettk@users.noreply.github.com>
* parallel tests with xdist
* add pytest-xdist as dev dep
* put back spiff
* update messaging
* get more in line with main
---------
Co-authored-by: burnettk <burnettk@users.noreply.github.com>
Co-authored-by: jasquat <jasquat@users.noreply.github.com>
* WIP: some updates to support new spiff w/ burnettk
* unit tests are passing
* all tests except message tests are passing
* fixed usage of catch message event w/ burnettk
* messages are working again w/ burnettk
* uncommented remaining message tests w/ burnettk
* fixed cypress tests w/ burnettk
* use main for spiffworkflow
---------
Co-authored-by: jasquat <jasquat@users.noreply.github.com>
* Bump flask for safety
* let snyk check flask again w/ burnettk
* attempt to use the same revision for front w/ burnettk
---------
Co-authored-by: jasquat <jasquat@users.noreply.github.com>
SpiffWorkflow -
- start_messages function should return message names, not ids.
- don't catch external thrown messages within the same workflow process
- add an expected value to the Correlation Property Model so we can use this well defined class as an external communication tool (rather than building an arbitrary dictionary)
- Added a "get_awaiting_correlations" to an event, so we can get a list of the correlation properties related to the workflows currently defined correlation values.
- workflows.waiting_events() function now returns the above awaiting correlations as the value on returned message events
Backend
- Dropping MessageModel and MessageCorrelationProperties - at least for now. We don't need them to send / receive messages though we may eventually want to track the messages and correlations defined across the system - these things (which are ever changing) should not be directly connected to the Messages which may be in flux - and the cross relationships between the tables could cause unexpected and unceissary errors. Commented out the caching logic so we can turn this back on later.
- Slight improvement to API Errors
- MessageInstances are no longer in a many-to-many relationship with Correlations - Each message instance has a unique set of message correlations specific to the instance.
- Message Instances have users, and can be linked through a "counterpart_id" so you can see what send is connected to what recieve.
- Message Correlations are connected to recieving message instances. It is not to a process instance, and not to a message model. They now include the expected value and retrieval expression required to validate an incoming message.
- A process instance is not connected to message correlations.
- Message Instances are not always tied to a process instance (for example, a Send Message from an API)
- API calls to create a message use the same logic as all other message catching code.
- Make use of the new waiting_events() method to check for any new recieve messages in the workflow (much easier than
churning through all of the tasks)
- One giant mother of a migration.
jasquat
burnettk
jasquat
Kevin Burnett
jbirddog
danfunk
Jon Herron