2. Added two api endpoints that will allow us to get all the logs for a specific workflow or study.
3. Assured that requests for logs are paginated, sortable, and can be limited to a specific code if needed.
4. Assure that we only use logging levels that match the log levels of Python.
Enum Label was depending on the options attribute not existing in some situtations, which is a bad assumption. Rather, check for specific properties, and call back to using options as the default.
Assure we raise more thoughtful error messages when running getting exceptions in engine tasks.
Field Options should always be available now due to a fix in Spiffworkflow.
Removing the spreadsheet.value.column and data.value.column so we just have value.column for both.
Improving the __str__ function in the ApiError class, to make debugging a little easier.
Adding a "validate_all" flask command, to help us track down any issues with current workflows in production (use this in concert with sync_with_testing)
Fixed logs of tests.
removed fact_runner.py, a very early and crufty bit of code.
Migrating the complete_template script stuff to JinjaService.
Having trouble with the tools stuff.
Pulled back to spot where test pass using CompleteTemplate
There was a problem with the python script engine as well that wasn't handling the de-serialize properly and didn't correctly pick back up on the script engine, and the renaming of methods in PythonScriptEngine created some conflicts with the way we override functions.
We were not handling ldap looks up efficiently, and this was also breaking in Study Info.
Finally we had a bug in SpiffWorkflow that did not allow us to reset back to the previous task in some cases where nested call activities happen far later in the process and are currently active when the reset is created.
Assure that if we generate a default value for a date in the task data, it is stored as an ISO String.
remove any unserializable data from the task_data when an error is encountered, rather than just dropping all the task_data. This case seems to happen a lot and it leaves us with nothing to go on.
- The `all_specifications` method is now explicit in what it returns; either `library`, `standalone`, or `regular` workflow specs
- When we add/edit a workflow spec, we make sure that `library` and `standalone` workflow specs do not get a category_id
