bee868d38 Merge pull request #163 from sartography/feature/process_name_for_log_list
c0da286d9 use workflow_spec to match task_spec naming w/ burnettk
ac9e11927 Merge commit '71f8c94096534112c8a08f202f8bb0e6f81ed92f' into main
5bf6f3814 prefer the bpmn process name over the identifier on the logs list page w/ burnettk
dc511b082 workflow.catch() was nice, in that it is where we could send events and messages. With this change sending an event to catch will behave incorrectly for BPMN Messages. Only sending it to the right method will create the desired result. It also adds a lot of additional code. Would love a careful review of this, and any optimizations anyone can think of.
git-subtree-dir: SpiffWorkflow
git-subtree-split: bee868d38b2c3da680c7a96b6a634d16b90d5861
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
