cr-connect-workflow

Author	SHA1	Message	Date
Dan Funk	dba41f4759	Ludicrously stupid launch in a refactor of the way all files work in the system at a time where I crave sleep and peace above all other things. Added a File class, that we wrap around the FileModel so the api endpoints don't change, but File no longer holds refences to versions or dates of the file_data model, we figure this out based on a clean database structure. The ApprovalFile is directly related to the file_data_model - so no chance that a reviewer would review the incorrect version of a file.py Noticed that our FileType enum called "bpmn" "bpmm", hope this doesn't screw someone up. Workflows are directly related to the data_models that create the workflow spec it needs. So the files should always be there. There are no more hashes, and thus no more hash errors where it can't find the files to rebuild the workflow.py Not much to report here, other than I broke every single test in the system at one point. So I'm super concerned about this, and will be testing it a lot before creating the pull request.	2020-05-28 20:03:50 -04:00
Dan Funk	971d9a58e9	As we now have an approval_service.py, I moved all the business logic into this service and out of the request_approval.py script. And moved all tests for these features into a test file for the service. Will make it easier to cross reference what is happening, as everything all happens in one file. As many of the scripts need to know the workflow, and it's down in a weird parameter, moved this so it is passed in each time.	2020-05-24 16:13:15 -04:00
Carlos Lopez	49eb4b3f98	Making working endpoints for approvals	2020-05-23 23:53:48 -06:00

Author

SHA1

Message

Date

Dan Funk

dba41f4759

Ludicrously stupid launch in a refactor of the way all files work in the system at a time where I crave sleep and peace above all other things.

Added a File class, that we wrap around the FileModel so the api endpoints don't change, but File no longer holds refences to versions or dates of the file_data model, we
figure this out based on a clean database structure.

The ApprovalFile is directly related to the file_data_model - so no chance that a reviewer would review the incorrect version of a file.py

Noticed that our FileType enum called "bpmn" "bpmm", hope this doesn't screw someone up.

Workflows are directly related to the data_models that create the workflow spec it needs.  So the files should always be there.  There are no more hashes, and thus no more hash errors where it can't find the files to rebuild the workflow.py

Not much to report here, other than I broke every single test in the system at one point.  So I'm super concerned about this, and will be testing it a lot before creating the pull request.

2020-05-28 20:03:50 -04:00

Dan Funk

971d9a58e9

As we now have an approval_service.py, I moved all the business logic into this service and out of the request_approval.py script. And moved all tests for these features into a test file for the service. Will make it easier to cross reference what is happening, as everything all happens in one file.

As many of the scripts need to know the workflow, and it's down in a weird parameter, moved this so it is passed in each time.

2020-05-24 16:13:15 -04:00

Carlos Lopez

49eb4b3f98

Making working endpoints for approvals

2020-05-23 23:53:48 -06:00

3 Commits