a547888ef run_pyl
53378437d BPMN.io -- Just show the message names not the ids - to assure we are only exposing the names. 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.
git-subtree-dir: bpmn-js-spiffworkflow
git-subtree-split: a547888ef102046bab983b9004f07d4398e9a1bc
4fd946be4 Merging main
453bdb246 run_pyl
b5a8ff01b Needed an additional check for empty correlation keys - which on a RECEIVE message, should always match anything.
b583f84cc lint w/ burnettk
fd4d7d13b removed some unused code from task and fixed the logs table a bit w/ burnettk
6f17e71e6 avoid using task-data endpoint for task data and only use it to get tasks based on spiff step instead
669c29595 removed task-data endpoints since we no longer need them w/ burnettk
5f25fffe0 added api to get task data and do not return from task data list anymore w/ burnettk
373c4f184 Merge remote-tracking branch 'origin/main' into feature/message_fixes
e40c12ac8 turn on sentry detailed tracing for task-data w/ burnettk
d7861aae2 Merge branch 'main' into feature/message_fixes
0a9f2480d work in progress - * Link between message instance and correlations is now a link table and many-to-many relationships as recommended by SQLAlchemy * Use the correlation keys, not the process id when accepting api messages.
git-subtree-dir: spiffworkflow-frontend
git-subtree-split: 4fd946be4ff716bfd1664aca8d75cb6f709b53eb
