The problem was that it was returning the first EndEvent it found, not the last one. This caused a problem when we had a CallActivity which has its own EndEvent.
Fixes#399
Most noteable is the addition of the line on which the error occurs for script tasks. It will report the line number and pass back the content of
the line that failed.
The validator only returns the first error it encounters, as it's clear that all we ever get right now is two of the same error.
Did a lot of work between this and spiffworkflow to remove all the places where we obfuscate or drop details as we converted between workflowExceptions and APIExceptions.
Dropped the python levenshtein dependency, in favor of just rolling a simple one ourselves in Spiffworkflow.
Seems that sqlalchemy now has a hard time incrementing sequences, so putting in a fix for this.
Upgrading many of our libraries, to avoid any disconnects as we try to handle security patches from these automated bumps.
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.
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.
It is not complete, but is in a state where we can start to interact with the front end.
Two tests are failing.
Committing so I can work on an error for Alex.
mike cullerton
Kelly McDonald
Dan
Mike Cullerton