Will also need to update the error handling BPMN process so it provides correlation keys. We should add a task that will
alert you when you create a message object without setting correlation keys - as they are required per the specification.
1) Type Safe checking on correlation properties (no more str())
2) A running workflows Correlations are once again at the key level.
# Backend
1) Both send and receive messages can have correlation_keys - and we compare these to each other to quickly assure a match (if they both exist - otherwise we fall back to comparing the properties on the receive to the sending messages payload)
2) Cleaned up the migrations to just one file
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.
* Clear out complex get_message_instance_receive how that many-to-many works.
* Create decent error messages when correlations fail
* Move correlation checks into the MessageInstance class
* The APIError could bomb out ugly if it hit a workflow exception with not Task Spec.
* 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.
Request "profile" scope over OpenID so we can get a few more bits of information when avilable.
Add a "clear_perissions" script
Add an "add_permissions" script
Add an "add_permissions" script
When logging in for the first time, check for any awaiting permissions and assign them.
Add "enumerate" as a whitelisted function to React Schema
Add a "display_name" to the user table
Add a test for adding a new permission
Add a test for adding a user to group
Adding a test for deleting all permissions.
Adding a display name for the user table
Request email from open id clients, as this would provide a handy way to uniquely reference users when assigning to groups.
During Login do a lookup on email if possible -- so that permissions assignments based on email can be connected when sigining in through openid.
Don't use "open_id" for the service name on user accounts, use the iss string provided through open id, this will allow us to support more than one open id platform.
Update the KeyCloak configuration so it is able to return email addresses for users -- which will make permission assignment easier in the future.
Removed several unused commands in the user_service class.
jasquat
Dan
jbirddog
burnettk
Kevin Burnett
jasquat
mike cullerton
Jon Herron