Each entry in status is a dictionary with 'status' and 'message' keys.
We updated the StudyService._update_status_of_workflow_meta method to accommodate the master workflow changes.
Changed the order of some if statements so we move forward while we have good data, and run all the error states at the end.
Added some comments to explain the cascading if statements
We changed the names of private methods to begin with one underscore, so they work in the test environment.
Changed some internal calls to accommodate the underscore change.
It used to return `True`, and this caused shield validation to fail when looping over the results of `get_study_associates`.
(You can't loop over a boolean)
Added a for loop in `study_sponsors_associate.bpmn` to test for this.
Moved `BaseTest` import to the top of `test_study_associate_script` because debug was failing.
I've re-worked the workflow form endpoint, so that it only accepts the data that should be in the form, and ignores any other values that come back from the front end. It seems Formly has some bugs that were introducing confusing information, and I want everything to behave consistently.
I had to re-work some of the tests, which were relying on an ability to set data through a form post without having a corresponding form to do so.
Email Script:
- The email script now accepts 3 keyword arguments; subject, recipients, and cc.
- Subject and recipients are required.
- Recipients (and cc) can be an email address or list of addresses.
- You can use the string 'associated' in place of an email address, in which case we look up the users associated with a study that have send_email set to True.
- Moved some helper methods to email_service.
Email Service:
- Added cc argument
- Added helper methods previously in email script.
- Modified get_rendered_content to accept message and data directly. Previously, we passed in the task and grabbed them from there. Now we can use the method outside a task.
We now accept subject, address, body (the email message), and possible data.
We now use email_service to send the message, and wrap it with the CR Connect html formatting.
**** We import DEFAULT_SENDER from config.default. Will this be a problem on testing and production? ****
Subject, address and message are required.
Data is not required.
Message is in the body of the request.
Subject, address, and data are in the query string.
To do so, I changed the WorkflowProcessor's reset method to be static, it will try to instantiate the current workflow and execute a cancel_notify event, but if that fails, it will continue and always return a new workflow processor using the latest spec.
While working on this ticket I found a logic error in the test. I expected both default_value and value_expression. It turns out the default_value is always there, it's just null if we don't set it.
Modified the existing test for hidden and required, and added tests to make sure my passing logic is now correct.
So far, there are two known errors.
- Missing condition type (Ticket 178)
- Invalid property value in extensions tab for display_name (No ticket for this error)
We now have the option of using regular expressions to pull task_id, etc. from an error to pass back to the user in the hint.
