2020-07-07 21:16:33 +00:00
|
|
|
from copy import copy
|
2020-05-04 14:57:09 +00:00
|
|
|
from datetime import datetime
|
Created a "StudyService" and moved all complex logic around study manipulation out of the study api, and this service, as things were getting complicated. The Workflow Processor no longer creates the WorkflowModel, the study object handles that, and only passes the model into the workflow processor when it is ready to start the workflow.
Created a Study object (seperate from the StudyModel) that can cronstructed on request, and contains a different data structure than we store in the DB. This allows us to return underlying Categories and Workflows in a clean way.
Added a new status to workflows called "not_started", meaning we have not yet instantiated a processor or created a BPMN, they have no version yet and no stored data, just the possiblity of being started.
The Top Level Workflow or "Master" workflow is now a part of the sample data, and loaded at all times.
Removed the ability to "add a workflow to a study" and "remove a workflow from a study", a study contains all possible workflows by definition.
Example data no longer creates users or studies, it just creates the specs.
2020-03-30 12:00:16 +00:00
|
|
|
from typing import List
|
|
|
|
|
2020-05-11 21:04:05 +00:00
|
|
|
import requests
|
Created a "StudyService" and moved all complex logic around study manipulation out of the study api, and this service, as things were getting complicated. The Workflow Processor no longer creates the WorkflowModel, the study object handles that, and only passes the model into the workflow processor when it is ready to start the workflow.
Created a Study object (seperate from the StudyModel) that can cronstructed on request, and contains a different data structure than we store in the DB. This allows us to return underlying Categories and Workflows in a clean way.
Added a new status to workflows called "not_started", meaning we have not yet instantiated a processor or created a BPMN, they have no version yet and no stored data, just the possiblity of being started.
The Top Level Workflow or "Master" workflow is now a part of the sample data, and loaded at all times.
Removed the ability to "add a workflow to a study" and "remove a workflow from a study", a study contains all possible workflows by definition.
Example data no longer creates users or studies, it just creates the specs.
2020-03-30 12:00:16 +00:00
|
|
|
from SpiffWorkflow import WorkflowException
|
2020-05-30 19:37:04 +00:00
|
|
|
from SpiffWorkflow.exceptions import WorkflowTaskExecException
|
2020-05-07 17:57:24 +00:00
|
|
|
from ldap3.core.exceptions import LDAPSocketOpenError
|
Created a "StudyService" and moved all complex logic around study manipulation out of the study api, and this service, as things were getting complicated. The Workflow Processor no longer creates the WorkflowModel, the study object handles that, and only passes the model into the workflow processor when it is ready to start the workflow.
Created a Study object (seperate from the StudyModel) that can cronstructed on request, and contains a different data structure than we store in the DB. This allows us to return underlying Categories and Workflows in a clean way.
Added a new status to workflows called "not_started", meaning we have not yet instantiated a processor or created a BPMN, they have no version yet and no stored data, just the possiblity of being started.
The Top Level Workflow or "Master" workflow is now a part of the sample data, and loaded at all times.
Removed the ability to "add a workflow to a study" and "remove a workflow from a study", a study contains all possible workflows by definition.
Example data no longer creates users or studies, it just creates the specs.
2020-03-30 12:00:16 +00:00
|
|
|
|
2020-05-07 17:57:24 +00:00
|
|
|
from crc import db, session, app
|
Created a "StudyService" and moved all complex logic around study manipulation out of the study api, and this service, as things were getting complicated. The Workflow Processor no longer creates the WorkflowModel, the study object handles that, and only passes the model into the workflow processor when it is ready to start the workflow.
Created a Study object (seperate from the StudyModel) that can cronstructed on request, and contains a different data structure than we store in the DB. This allows us to return underlying Categories and Workflows in a clean way.
Added a new status to workflows called "not_started", meaning we have not yet instantiated a processor or created a BPMN, they have no version yet and no stored data, just the possiblity of being started.
The Top Level Workflow or "Master" workflow is now a part of the sample data, and loaded at all times.
Removed the ability to "add a workflow to a study" and "remove a workflow from a study", a study contains all possible workflows by definition.
Example data no longer creates users or studies, it just creates the specs.
2020-03-30 12:00:16 +00:00
|
|
|
from crc.api.common import ApiError
|
2020-06-01 01:15:40 +00:00
|
|
|
from crc.models.file import FileModel, FileModelSchema, File
|
2020-06-02 22:17:00 +00:00
|
|
|
from crc.models.ldap import LdapSchema
|
Created a "StudyService" and moved all complex logic around study manipulation out of the study api, and this service, as things were getting complicated. The Workflow Processor no longer creates the WorkflowModel, the study object handles that, and only passes the model into the workflow processor when it is ready to start the workflow.
Created a Study object (seperate from the StudyModel) that can cronstructed on request, and contains a different data structure than we store in the DB. This allows us to return underlying Categories and Workflows in a clean way.
Added a new status to workflows called "not_started", meaning we have not yet instantiated a processor or created a BPMN, they have no version yet and no stored data, just the possiblity of being started.
The Top Level Workflow or "Master" workflow is now a part of the sample data, and loaded at all times.
Removed the ability to "add a workflow to a study" and "remove a workflow from a study", a study contains all possible workflows by definition.
Example data no longer creates users or studies, it just creates the specs.
2020-03-30 12:00:16 +00:00
|
|
|
from crc.models.protocol_builder import ProtocolBuilderStudy, ProtocolBuilderStatus
|
2020-07-31 03:03:11 +00:00
|
|
|
from crc.models.study import StudyModel, Study, StudyStatus, Category, WorkflowMetadata
|
2020-07-27 21:05:01 +00:00
|
|
|
from crc.models.task_event import TaskEventModel, TaskEvent
|
Created a "StudyService" and moved all complex logic around study manipulation out of the study api, and this service, as things were getting complicated. The Workflow Processor no longer creates the WorkflowModel, the study object handles that, and only passes the model into the workflow processor when it is ready to start the workflow.
Created a Study object (seperate from the StudyModel) that can cronstructed on request, and contains a different data structure than we store in the DB. This allows us to return underlying Categories and Workflows in a clean way.
Added a new status to workflows called "not_started", meaning we have not yet instantiated a processor or created a BPMN, they have no version yet and no stored data, just the possiblity of being started.
The Top Level Workflow or "Master" workflow is now a part of the sample data, and loaded at all times.
Removed the ability to "add a workflow to a study" and "remove a workflow from a study", a study contains all possible workflows by definition.
Example data no longer creates users or studies, it just creates the specs.
2020-03-30 12:00:16 +00:00
|
|
|
from crc.models.workflow import WorkflowSpecCategoryModel, WorkflowModel, WorkflowSpecModel, WorkflowState, \
|
|
|
|
WorkflowStatus
|
2020-07-27 21:05:01 +00:00
|
|
|
from crc.services.approval_service import ApprovalService
|
2020-04-23 23:25:01 +00:00
|
|
|
from crc.services.file_service import FileService
|
2020-05-07 17:57:24 +00:00
|
|
|
from crc.services.ldap_service import LdapService
|
Created a "StudyService" and moved all complex logic around study manipulation out of the study api, and this service, as things were getting complicated. The Workflow Processor no longer creates the WorkflowModel, the study object handles that, and only passes the model into the workflow processor when it is ready to start the workflow.
Created a Study object (seperate from the StudyModel) that can cronstructed on request, and contains a different data structure than we store in the DB. This allows us to return underlying Categories and Workflows in a clean way.
Added a new status to workflows called "not_started", meaning we have not yet instantiated a processor or created a BPMN, they have no version yet and no stored data, just the possiblity of being started.
The Top Level Workflow or "Master" workflow is now a part of the sample data, and loaded at all times.
Removed the ability to "add a workflow to a study" and "remove a workflow from a study", a study contains all possible workflows by definition.
Example data no longer creates users or studies, it just creates the specs.
2020-03-30 12:00:16 +00:00
|
|
|
from crc.services.protocol_builder import ProtocolBuilderService
|
|
|
|
from crc.services.workflow_processor import WorkflowProcessor
|
|
|
|
|
|
|
|
|
|
|
|
class StudyService(object):
|
|
|
|
"""Provides common tools for working with a Study"""
|
|
|
|
|
|
|
|
@staticmethod
|
|
|
|
def get_studies_for_user(user):
|
|
|
|
"""Returns a list of all studies for the given user."""
|
|
|
|
db_studies = session.query(StudyModel).filter_by(user_uid=user.uid).all()
|
|
|
|
studies = []
|
|
|
|
for study_model in db_studies:
|
|
|
|
studies.append(StudyService.get_study(study_model.id, study_model))
|
|
|
|
return studies
|
|
|
|
|
2020-05-22 15:46:03 +00:00
|
|
|
@staticmethod
|
A major refactor of how we search and store files, as there was a lot of confusing bits in here.
From an API point of view you can do the following (and only the following)
/files?workflow_spec_id=x
* You can find all files associated with a workflow_spec_id, and add a file with a workflow_spec_id
/files?workflow_id=x
* You can find all files associated with a workflow_id, and add a file that is directly associated with the workflow
/files?workflow_id=x&form_field_key=y
* You can find all files associated with a form element on a running workflow, and add a new file.
Note: you can add multiple files to the same form_field_key, IF they have different file names. If the same name, the original file is archived,
and the new file takes its place.
The study endpoints always return a list of the file metadata associated with the study. Removed /studies-files, but there is an
endpoint called
/studies/all - that returns all the studies in the system, and does include their files.
On a deeper level:
The File model no longer contains:
- study_id,
- task_id,
- form_field_key
Instead, if the file is associated with workflow - then that is the one way it is connected to the study, and we use this relationship to find files for a study.
A file is never associated with a task_id, as these change when the workflow is reloaded.
The form_field_key must match the irb_doc_code, so when requesting files for a form field, we just look up the irb_doc_code.
2020-05-28 12:27:26 +00:00
|
|
|
def get_all_studies_with_files():
|
2020-05-22 15:46:03 +00:00
|
|
|
"""Returns a list of all studies"""
|
|
|
|
db_studies = session.query(StudyModel).all()
|
A major refactor of how we search and store files, as there was a lot of confusing bits in here.
From an API point of view you can do the following (and only the following)
/files?workflow_spec_id=x
* You can find all files associated with a workflow_spec_id, and add a file with a workflow_spec_id
/files?workflow_id=x
* You can find all files associated with a workflow_id, and add a file that is directly associated with the workflow
/files?workflow_id=x&form_field_key=y
* You can find all files associated with a form element on a running workflow, and add a new file.
Note: you can add multiple files to the same form_field_key, IF they have different file names. If the same name, the original file is archived,
and the new file takes its place.
The study endpoints always return a list of the file metadata associated with the study. Removed /studies-files, but there is an
endpoint called
/studies/all - that returns all the studies in the system, and does include their files.
On a deeper level:
The File model no longer contains:
- study_id,
- task_id,
- form_field_key
Instead, if the file is associated with workflow - then that is the one way it is connected to the study, and we use this relationship to find files for a study.
A file is never associated with a task_id, as these change when the workflow is reloaded.
The form_field_key must match the irb_doc_code, so when requesting files for a form field, we just look up the irb_doc_code.
2020-05-28 12:27:26 +00:00
|
|
|
studies = []
|
|
|
|
for s in db_studies:
|
|
|
|
study = Study.from_model(s)
|
|
|
|
study.files = FileService.get_files_for_study(study.id)
|
|
|
|
studies.append(study)
|
|
|
|
return studies
|
2020-05-22 15:46:03 +00:00
|
|
|
|
Created a "StudyService" and moved all complex logic around study manipulation out of the study api, and this service, as things were getting complicated. The Workflow Processor no longer creates the WorkflowModel, the study object handles that, and only passes the model into the workflow processor when it is ready to start the workflow.
Created a Study object (seperate from the StudyModel) that can cronstructed on request, and contains a different data structure than we store in the DB. This allows us to return underlying Categories and Workflows in a clean way.
Added a new status to workflows called "not_started", meaning we have not yet instantiated a processor or created a BPMN, they have no version yet and no stored data, just the possiblity of being started.
The Top Level Workflow or "Master" workflow is now a part of the sample data, and loaded at all times.
Removed the ability to "add a workflow to a study" and "remove a workflow from a study", a study contains all possible workflows by definition.
Example data no longer creates users or studies, it just creates the specs.
2020-03-30 12:00:16 +00:00
|
|
|
@staticmethod
|
|
|
|
def get_study(study_id, study_model: StudyModel = None):
|
|
|
|
"""Returns a study model that contains all the workflows organized by category.
|
|
|
|
IMPORTANT: This is intended to be a lightweight call, it should never involve
|
|
|
|
loading up and executing all the workflows in a study to calculate information."""
|
|
|
|
if not study_model:
|
|
|
|
study_model = session.query(StudyModel).filter_by(id=study_id).first()
|
|
|
|
study = Study.from_model(study_model)
|
|
|
|
study.categories = StudyService.get_categories()
|
|
|
|
workflow_metas = StudyService.__get_workflow_metas(study_id)
|
2020-06-02 22:17:00 +00:00
|
|
|
study.approvals = ApprovalService.get_approvals_for_study(study.id)
|
2020-06-01 01:15:40 +00:00
|
|
|
files = FileService.get_files_for_study(study.id)
|
|
|
|
files = (File.from_models(model, FileService.get_file_data(model.id),
|
|
|
|
FileService.get_doc_dictionary()) for model in files)
|
|
|
|
study.files = list(files)
|
Refactor the document details scripts. Now there is one script, it returns data in a consistent format, and has all the details required. The script is located in StudyInfo, with the argument documents. Make note that it returns a dictionary of ALL the documents, with a field to mark which ones are required according to the protocol builder. Others may become required if a workflow determines such, in which case the workflow will enforce this, and the document will have a count > 0, and additional details in a list of files within the document. I modified the XLS file to use lower case variable names, because it disturbed me, and we have to reference them frequently. Removed devious "as_object" variable on get_required_docs, so it behaves like the other methods all the time, and returns a dictionary. All the core business logic for finding the documents list now resides in the StudyService.
Because this changes the endpoint for all existing document details, I've modified all the test and static bpmn files to use the new format.
Shorting up the SponsorsList.xls file makes for slightly faster tests. seems senseless to load 5000 everytime we reset the data.
Tried to test all of this carefully in the test_study_details_documents.py test.
2020-04-29 19:08:11 +00:00
|
|
|
# Calling this line repeatedly is very very slow. It creates the
|
2020-07-06 20:01:43 +00:00
|
|
|
# master spec and runs it. Don't execute this for Abandoned studies, as
|
|
|
|
# we don't have the information to process them.
|
2020-07-31 03:03:11 +00:00
|
|
|
if study.status != StudyStatus.abandoned:
|
2020-07-06 20:01:43 +00:00
|
|
|
status = StudyService.__get_study_status(study_model)
|
|
|
|
study.warnings = StudyService.__update_status_of_workflow_meta(workflow_metas, status)
|
Created a "StudyService" and moved all complex logic around study manipulation out of the study api, and this service, as things were getting complicated. The Workflow Processor no longer creates the WorkflowModel, the study object handles that, and only passes the model into the workflow processor when it is ready to start the workflow.
Created a Study object (seperate from the StudyModel) that can cronstructed on request, and contains a different data structure than we store in the DB. This allows us to return underlying Categories and Workflows in a clean way.
Added a new status to workflows called "not_started", meaning we have not yet instantiated a processor or created a BPMN, they have no version yet and no stored data, just the possiblity of being started.
The Top Level Workflow or "Master" workflow is now a part of the sample data, and loaded at all times.
Removed the ability to "add a workflow to a study" and "remove a workflow from a study", a study contains all possible workflows by definition.
Example data no longer creates users or studies, it just creates the specs.
2020-03-30 12:00:16 +00:00
|
|
|
|
2020-07-06 20:01:43 +00:00
|
|
|
# Group the workflows into their categories.
|
|
|
|
for category in study.categories:
|
|
|
|
category.workflows = {w for w in workflow_metas if w.category_id == category.id}
|
Created a "StudyService" and moved all complex logic around study manipulation out of the study api, and this service, as things were getting complicated. The Workflow Processor no longer creates the WorkflowModel, the study object handles that, and only passes the model into the workflow processor when it is ready to start the workflow.
Created a Study object (seperate from the StudyModel) that can cronstructed on request, and contains a different data structure than we store in the DB. This allows us to return underlying Categories and Workflows in a clean way.
Added a new status to workflows called "not_started", meaning we have not yet instantiated a processor or created a BPMN, they have no version yet and no stored data, just the possiblity of being started.
The Top Level Workflow or "Master" workflow is now a part of the sample data, and loaded at all times.
Removed the ability to "add a workflow to a study" and "remove a workflow from a study", a study contains all possible workflows by definition.
Example data no longer creates users or studies, it just creates the specs.
2020-03-30 12:00:16 +00:00
|
|
|
|
|
|
|
return study
|
|
|
|
|
|
|
|
@staticmethod
|
|
|
|
def delete_study(study_id):
|
2020-04-06 17:08:17 +00:00
|
|
|
session.query(TaskEventModel).filter_by(study_id=study_id).delete()
|
2020-04-29 20:07:39 +00:00
|
|
|
for workflow in session.query(WorkflowModel).filter_by(study_id=study_id):
|
2020-05-25 16:29:05 +00:00
|
|
|
StudyService.delete_workflow(workflow)
|
Created a "StudyService" and moved all complex logic around study manipulation out of the study api, and this service, as things were getting complicated. The Workflow Processor no longer creates the WorkflowModel, the study object handles that, and only passes the model into the workflow processor when it is ready to start the workflow.
Created a Study object (seperate from the StudyModel) that can cronstructed on request, and contains a different data structure than we store in the DB. This allows us to return underlying Categories and Workflows in a clean way.
Added a new status to workflows called "not_started", meaning we have not yet instantiated a processor or created a BPMN, they have no version yet and no stored data, just the possiblity of being started.
The Top Level Workflow or "Master" workflow is now a part of the sample data, and loaded at all times.
Removed the ability to "add a workflow to a study" and "remove a workflow from a study", a study contains all possible workflows by definition.
Example data no longer creates users or studies, it just creates the specs.
2020-03-30 12:00:16 +00:00
|
|
|
session.query(StudyModel).filter_by(id=study_id).delete()
|
2020-04-08 17:28:43 +00:00
|
|
|
session.commit()
|
Created a "StudyService" and moved all complex logic around study manipulation out of the study api, and this service, as things were getting complicated. The Workflow Processor no longer creates the WorkflowModel, the study object handles that, and only passes the model into the workflow processor when it is ready to start the workflow.
Created a Study object (seperate from the StudyModel) that can cronstructed on request, and contains a different data structure than we store in the DB. This allows us to return underlying Categories and Workflows in a clean way.
Added a new status to workflows called "not_started", meaning we have not yet instantiated a processor or created a BPMN, they have no version yet and no stored data, just the possiblity of being started.
The Top Level Workflow or "Master" workflow is now a part of the sample data, and loaded at all times.
Removed the ability to "add a workflow to a study" and "remove a workflow from a study", a study contains all possible workflows by definition.
Example data no longer creates users or studies, it just creates the specs.
2020-03-30 12:00:16 +00:00
|
|
|
|
2020-04-29 20:07:39 +00:00
|
|
|
@staticmethod
|
2020-05-25 16:29:05 +00:00
|
|
|
def delete_workflow(workflow):
|
|
|
|
for file in session.query(FileModel).filter_by(workflow_id=workflow.id).all():
|
2020-04-29 20:07:39 +00:00
|
|
|
FileService.delete_file(file.id)
|
2020-06-12 17:46:10 +00:00
|
|
|
for dep in workflow.dependencies:
|
|
|
|
session.delete(dep)
|
2020-05-25 16:29:05 +00:00
|
|
|
session.query(TaskEventModel).filter_by(workflow_id=workflow.id).delete()
|
|
|
|
session.query(WorkflowModel).filter_by(id=workflow.id).delete()
|
2020-08-04 19:50:29 +00:00
|
|
|
session.commit()
|
2020-04-29 20:07:39 +00:00
|
|
|
|
Created a "StudyService" and moved all complex logic around study manipulation out of the study api, and this service, as things were getting complicated. The Workflow Processor no longer creates the WorkflowModel, the study object handles that, and only passes the model into the workflow processor when it is ready to start the workflow.
Created a Study object (seperate from the StudyModel) that can cronstructed on request, and contains a different data structure than we store in the DB. This allows us to return underlying Categories and Workflows in a clean way.
Added a new status to workflows called "not_started", meaning we have not yet instantiated a processor or created a BPMN, they have no version yet and no stored data, just the possiblity of being started.
The Top Level Workflow or "Master" workflow is now a part of the sample data, and loaded at all times.
Removed the ability to "add a workflow to a study" and "remove a workflow from a study", a study contains all possible workflows by definition.
Example data no longer creates users or studies, it just creates the specs.
2020-03-30 12:00:16 +00:00
|
|
|
@staticmethod
|
|
|
|
def get_categories():
|
|
|
|
"""Returns a list of category objects, in the correct order."""
|
|
|
|
cat_models = db.session.query(WorkflowSpecCategoryModel) \
|
|
|
|
.order_by(WorkflowSpecCategoryModel.display_order).all()
|
|
|
|
categories = []
|
|
|
|
for cat_model in cat_models:
|
|
|
|
categories.append(Category(cat_model))
|
|
|
|
return categories
|
|
|
|
|
2020-04-23 18:40:05 +00:00
|
|
|
@staticmethod
|
|
|
|
def get_approvals(study_id):
|
2020-04-24 13:45:55 +00:00
|
|
|
"""Returns a list of non-hidden approval workflows."""
|
|
|
|
study = StudyService.get_study(study_id)
|
|
|
|
cat = next(c for c in study.categories if c.name == 'approvals')
|
2020-04-23 18:40:05 +00:00
|
|
|
|
|
|
|
approvals = []
|
2020-04-24 13:45:55 +00:00
|
|
|
for wf in cat.workflows:
|
|
|
|
if wf.state is WorkflowState.hidden:
|
|
|
|
continue
|
|
|
|
|
|
|
|
workflow = db.session.query(WorkflowModel).filter_by(id=wf.id).first()
|
2020-04-23 18:40:05 +00:00
|
|
|
approvals.append({
|
2020-04-24 03:32:20 +00:00
|
|
|
'study_id': study_id,
|
2020-04-24 13:45:55 +00:00
|
|
|
'workflow_id': wf.id,
|
|
|
|
'display_name': wf.display_name,
|
|
|
|
'display_order': wf.display_order or 0,
|
|
|
|
'name': wf.name,
|
|
|
|
'state': wf.state.value,
|
|
|
|
'status': wf.status.value,
|
2020-04-23 18:40:05 +00:00
|
|
|
'workflow_spec_id': workflow.workflow_spec_id,
|
|
|
|
})
|
2020-04-24 12:54:14 +00:00
|
|
|
|
|
|
|
approvals.sort(key=lambda k: k['display_order'])
|
2020-04-23 18:40:05 +00:00
|
|
|
return approvals
|
|
|
|
|
2020-04-23 23:25:01 +00:00
|
|
|
@staticmethod
|
|
|
|
def get_documents_status(study_id):
|
2020-05-06 15:25:50 +00:00
|
|
|
"""Returns a list of documents related to the study, and any file information
|
Refactor the document details scripts. Now there is one script, it returns data in a consistent format, and has all the details required. The script is located in StudyInfo, with the argument documents. Make note that it returns a dictionary of ALL the documents, with a field to mark which ones are required according to the protocol builder. Others may become required if a workflow determines such, in which case the workflow will enforce this, and the document will have a count > 0, and additional details in a list of files within the document. I modified the XLS file to use lower case variable names, because it disturbed me, and we have to reference them frequently. Removed devious "as_object" variable on get_required_docs, so it behaves like the other methods all the time, and returns a dictionary. All the core business logic for finding the documents list now resides in the StudyService.
Because this changes the endpoint for all existing document details, I've modified all the test and static bpmn files to use the new format.
Shorting up the SponsorsList.xls file makes for slightly faster tests. seems senseless to load 5000 everytime we reset the data.
Tried to test all of this carefully in the test_study_details_documents.py test.
2020-04-29 19:08:11 +00:00
|
|
|
that is available.."""
|
2020-04-23 23:25:01 +00:00
|
|
|
|
2020-05-22 18:37:49 +00:00
|
|
|
# Get PB required docs, if Protocol Builder Service is enabled.
|
2020-06-15 15:27:28 +00:00
|
|
|
if ProtocolBuilderService.is_enabled() and study_id is not None:
|
2020-05-22 18:37:49 +00:00
|
|
|
try:
|
|
|
|
pb_docs = ProtocolBuilderService.get_required_docs(study_id=study_id)
|
|
|
|
except requests.exceptions.ConnectionError as ce:
|
2020-07-02 22:10:33 +00:00
|
|
|
app.logger.error(f'Failed to connect to the Protocol Builder - {str(ce)}', exc_info=True)
|
2020-05-22 18:37:49 +00:00
|
|
|
pb_docs = []
|
|
|
|
else:
|
2020-05-11 21:04:05 +00:00
|
|
|
pb_docs = []
|
2020-04-23 23:25:01 +00:00
|
|
|
|
2020-05-22 18:37:49 +00:00
|
|
|
# Loop through all known document types, get the counts for those files,
|
|
|
|
# and use pb_docs to mark those as required.
|
2020-05-07 17:57:24 +00:00
|
|
|
doc_dictionary = FileService.get_reference_data(FileService.DOCUMENT_LIST, 'code', ['id'])
|
|
|
|
|
Refactor the document details scripts. Now there is one script, it returns data in a consistent format, and has all the details required. The script is located in StudyInfo, with the argument documents. Make note that it returns a dictionary of ALL the documents, with a field to mark which ones are required according to the protocol builder. Others may become required if a workflow determines such, in which case the workflow will enforce this, and the document will have a count > 0, and additional details in a list of files within the document. I modified the XLS file to use lower case variable names, because it disturbed me, and we have to reference them frequently. Removed devious "as_object" variable on get_required_docs, so it behaves like the other methods all the time, and returns a dictionary. All the core business logic for finding the documents list now resides in the StudyService.
Because this changes the endpoint for all existing document details, I've modified all the test and static bpmn files to use the new format.
Shorting up the SponsorsList.xls file makes for slightly faster tests. seems senseless to load 5000 everytime we reset the data.
Tried to test all of this carefully in the test_study_details_documents.py test.
2020-04-29 19:08:11 +00:00
|
|
|
documents = {}
|
|
|
|
for code, doc in doc_dictionary.items():
|
2020-04-24 03:32:20 +00:00
|
|
|
|
2020-05-27 02:42:49 +00:00
|
|
|
if ProtocolBuilderService.is_enabled():
|
2020-05-22 18:37:49 +00:00
|
|
|
pb_data = next((item for item in pb_docs if int(item['AUXDOCID']) == int(doc['id'])), None)
|
|
|
|
doc['required'] = False
|
|
|
|
if pb_data:
|
|
|
|
doc['required'] = True
|
|
|
|
|
2020-04-23 23:25:01 +00:00
|
|
|
doc['study_id'] = study_id
|
|
|
|
doc['code'] = code
|
2020-04-24 03:32:20 +00:00
|
|
|
|
Refactor the document details scripts. Now there is one script, it returns data in a consistent format, and has all the details required. The script is located in StudyInfo, with the argument documents. Make note that it returns a dictionary of ALL the documents, with a field to mark which ones are required according to the protocol builder. Others may become required if a workflow determines such, in which case the workflow will enforce this, and the document will have a count > 0, and additional details in a list of files within the document. I modified the XLS file to use lower case variable names, because it disturbed me, and we have to reference them frequently. Removed devious "as_object" variable on get_required_docs, so it behaves like the other methods all the time, and returns a dictionary. All the core business logic for finding the documents list now resides in the StudyService.
Because this changes the endpoint for all existing document details, I've modified all the test and static bpmn files to use the new format.
Shorting up the SponsorsList.xls file makes for slightly faster tests. seems senseless to load 5000 everytime we reset the data.
Tried to test all of this carefully in the test_study_details_documents.py test.
2020-04-29 19:08:11 +00:00
|
|
|
# Make a display name out of categories
|
|
|
|
name_list = []
|
|
|
|
for cat_key in ['category1', 'category2', 'category3']:
|
|
|
|
if doc[cat_key] not in ['', 'NULL']:
|
|
|
|
name_list.append(doc[cat_key])
|
|
|
|
doc['display_name'] = ' / '.join(name_list)
|
2020-04-23 23:25:01 +00:00
|
|
|
|
|
|
|
# For each file, get associated workflow status
|
A major refactor of how we search and store files, as there was a lot of confusing bits in here.
From an API point of view you can do the following (and only the following)
/files?workflow_spec_id=x
* You can find all files associated with a workflow_spec_id, and add a file with a workflow_spec_id
/files?workflow_id=x
* You can find all files associated with a workflow_id, and add a file that is directly associated with the workflow
/files?workflow_id=x&form_field_key=y
* You can find all files associated with a form element on a running workflow, and add a new file.
Note: you can add multiple files to the same form_field_key, IF they have different file names. If the same name, the original file is archived,
and the new file takes its place.
The study endpoints always return a list of the file metadata associated with the study. Removed /studies-files, but there is an
endpoint called
/studies/all - that returns all the studies in the system, and does include their files.
On a deeper level:
The File model no longer contains:
- study_id,
- task_id,
- form_field_key
Instead, if the file is associated with workflow - then that is the one way it is connected to the study, and we use this relationship to find files for a study.
A file is never associated with a task_id, as these change when the workflow is reloaded.
The form_field_key must match the irb_doc_code, so when requesting files for a form field, we just look up the irb_doc_code.
2020-05-28 12:27:26 +00:00
|
|
|
doc_files = FileService.get_files_for_study(study_id=study_id, irb_doc_code=code)
|
Refactor the document details scripts. Now there is one script, it returns data in a consistent format, and has all the details required. The script is located in StudyInfo, with the argument documents. Make note that it returns a dictionary of ALL the documents, with a field to mark which ones are required according to the protocol builder. Others may become required if a workflow determines such, in which case the workflow will enforce this, and the document will have a count > 0, and additional details in a list of files within the document. I modified the XLS file to use lower case variable names, because it disturbed me, and we have to reference them frequently. Removed devious "as_object" variable on get_required_docs, so it behaves like the other methods all the time, and returns a dictionary. All the core business logic for finding the documents list now resides in the StudyService.
Because this changes the endpoint for all existing document details, I've modified all the test and static bpmn files to use the new format.
Shorting up the SponsorsList.xls file makes for slightly faster tests. seems senseless to load 5000 everytime we reset the data.
Tried to test all of this carefully in the test_study_details_documents.py test.
2020-04-29 19:08:11 +00:00
|
|
|
doc['count'] = len(doc_files)
|
|
|
|
doc['files'] = []
|
2020-04-23 23:25:01 +00:00
|
|
|
for file in doc_files:
|
Refactor the document details scripts. Now there is one script, it returns data in a consistent format, and has all the details required. The script is located in StudyInfo, with the argument documents. Make note that it returns a dictionary of ALL the documents, with a field to mark which ones are required according to the protocol builder. Others may become required if a workflow determines such, in which case the workflow will enforce this, and the document will have a count > 0, and additional details in a list of files within the document. I modified the XLS file to use lower case variable names, because it disturbed me, and we have to reference them frequently. Removed devious "as_object" variable on get_required_docs, so it behaves like the other methods all the time, and returns a dictionary. All the core business logic for finding the documents list now resides in the StudyService.
Because this changes the endpoint for all existing document details, I've modified all the test and static bpmn files to use the new format.
Shorting up the SponsorsList.xls file makes for slightly faster tests. seems senseless to load 5000 everytime we reset the data.
Tried to test all of this carefully in the test_study_details_documents.py test.
2020-04-29 19:08:11 +00:00
|
|
|
doc['files'].append({'file_id': file.id,
|
A major refactor of how we search and store files, as there was a lot of confusing bits in here.
From an API point of view you can do the following (and only the following)
/files?workflow_spec_id=x
* You can find all files associated with a workflow_spec_id, and add a file with a workflow_spec_id
/files?workflow_id=x
* You can find all files associated with a workflow_id, and add a file that is directly associated with the workflow
/files?workflow_id=x&form_field_key=y
* You can find all files associated with a form element on a running workflow, and add a new file.
Note: you can add multiple files to the same form_field_key, IF they have different file names. If the same name, the original file is archived,
and the new file takes its place.
The study endpoints always return a list of the file metadata associated with the study. Removed /studies-files, but there is an
endpoint called
/studies/all - that returns all the studies in the system, and does include their files.
On a deeper level:
The File model no longer contains:
- study_id,
- task_id,
- form_field_key
Instead, if the file is associated with workflow - then that is the one way it is connected to the study, and we use this relationship to find files for a study.
A file is never associated with a task_id, as these change when the workflow is reloaded.
The form_field_key must match the irb_doc_code, so when requesting files for a form field, we just look up the irb_doc_code.
2020-05-28 12:27:26 +00:00
|
|
|
'workflow_id': file.workflow_id})
|
2020-04-23 23:25:01 +00:00
|
|
|
|
Refactor the document details scripts. Now there is one script, it returns data in a consistent format, and has all the details required. The script is located in StudyInfo, with the argument documents. Make note that it returns a dictionary of ALL the documents, with a field to mark which ones are required according to the protocol builder. Others may become required if a workflow determines such, in which case the workflow will enforce this, and the document will have a count > 0, and additional details in a list of files within the document. I modified the XLS file to use lower case variable names, because it disturbed me, and we have to reference them frequently. Removed devious "as_object" variable on get_required_docs, so it behaves like the other methods all the time, and returns a dictionary. All the core business logic for finding the documents list now resides in the StudyService.
Because this changes the endpoint for all existing document details, I've modified all the test and static bpmn files to use the new format.
Shorting up the SponsorsList.xls file makes for slightly faster tests. seems senseless to load 5000 everytime we reset the data.
Tried to test all of this carefully in the test_study_details_documents.py test.
2020-04-29 19:08:11 +00:00
|
|
|
# update the document status to match the status of the workflow it is in.
|
A major refactor of how we search and store files, as there was a lot of confusing bits in here.
From an API point of view you can do the following (and only the following)
/files?workflow_spec_id=x
* You can find all files associated with a workflow_spec_id, and add a file with a workflow_spec_id
/files?workflow_id=x
* You can find all files associated with a workflow_id, and add a file that is directly associated with the workflow
/files?workflow_id=x&form_field_key=y
* You can find all files associated with a form element on a running workflow, and add a new file.
Note: you can add multiple files to the same form_field_key, IF they have different file names. If the same name, the original file is archived,
and the new file takes its place.
The study endpoints always return a list of the file metadata associated with the study. Removed /studies-files, but there is an
endpoint called
/studies/all - that returns all the studies in the system, and does include their files.
On a deeper level:
The File model no longer contains:
- study_id,
- task_id,
- form_field_key
Instead, if the file is associated with workflow - then that is the one way it is connected to the study, and we use this relationship to find files for a study.
A file is never associated with a task_id, as these change when the workflow is reloaded.
The form_field_key must match the irb_doc_code, so when requesting files for a form field, we just look up the irb_doc_code.
2020-05-28 12:27:26 +00:00
|
|
|
if 'status' not in doc or doc['status'] is None:
|
2020-04-23 23:25:01 +00:00
|
|
|
workflow: WorkflowModel = session.query(WorkflowModel).filter_by(id=file.workflow_id).first()
|
|
|
|
doc['status'] = workflow.status.value
|
|
|
|
|
Refactor the document details scripts. Now there is one script, it returns data in a consistent format, and has all the details required. The script is located in StudyInfo, with the argument documents. Make note that it returns a dictionary of ALL the documents, with a field to mark which ones are required according to the protocol builder. Others may become required if a workflow determines such, in which case the workflow will enforce this, and the document will have a count > 0, and additional details in a list of files within the document. I modified the XLS file to use lower case variable names, because it disturbed me, and we have to reference them frequently. Removed devious "as_object" variable on get_required_docs, so it behaves like the other methods all the time, and returns a dictionary. All the core business logic for finding the documents list now resides in the StudyService.
Because this changes the endpoint for all existing document details, I've modified all the test and static bpmn files to use the new format.
Shorting up the SponsorsList.xls file makes for slightly faster tests. seems senseless to load 5000 everytime we reset the data.
Tried to test all of this carefully in the test_study_details_documents.py test.
2020-04-29 19:08:11 +00:00
|
|
|
documents[code] = doc
|
2020-04-23 23:25:01 +00:00
|
|
|
return documents
|
|
|
|
|
2020-05-07 17:57:24 +00:00
|
|
|
@staticmethod
|
2020-07-06 16:09:21 +00:00
|
|
|
def get_investigators(study_id, all=False):
|
2020-07-07 21:16:33 +00:00
|
|
|
"""Convert array of investigators from protocol builder into a dictionary keyed on the type. """
|
2020-05-07 17:57:24 +00:00
|
|
|
|
|
|
|
# Loop through all known investigator types as set in the reference file
|
|
|
|
inv_dictionary = FileService.get_reference_data(FileService.INVESTIGATOR_LIST, 'code')
|
|
|
|
|
|
|
|
# Get PB required docs
|
|
|
|
pb_investigators = ProtocolBuilderService.get_investigators(study_id=study_id)
|
|
|
|
|
2020-07-07 21:16:33 +00:00
|
|
|
# It is possible for the same type to show up more than once in some circumstances, in those events
|
|
|
|
# append a counter to the name.
|
|
|
|
investigators = {}
|
2020-05-07 17:57:24 +00:00
|
|
|
for i_type in inv_dictionary:
|
2020-07-07 21:16:33 +00:00
|
|
|
pb_data_entries = list(item for item in pb_investigators if item['INVESTIGATORTYPE'] == i_type)
|
|
|
|
entry_count = 0
|
|
|
|
investigators[i_type] = copy(inv_dictionary[i_type])
|
|
|
|
investigators[i_type]['user_id'] = None
|
|
|
|
for pb_data in pb_data_entries:
|
|
|
|
entry_count += 1
|
|
|
|
if entry_count == 1:
|
|
|
|
t = i_type
|
|
|
|
else:
|
|
|
|
t = i_type + "_" + str(entry_count)
|
|
|
|
investigators[t] = copy(inv_dictionary[i_type])
|
|
|
|
investigators[t]['user_id'] = pb_data["NETBADGEID"]
|
|
|
|
investigators[t].update(StudyService.get_ldap_dict_if_available(pb_data["NETBADGEID"]))
|
2020-07-06 16:09:21 +00:00
|
|
|
if not all:
|
2020-07-07 21:16:33 +00:00
|
|
|
investigators = dict(filter(lambda elem: elem[1]['user_id'] is not None, investigators.items()))
|
|
|
|
return investigators
|
2020-05-07 17:57:24 +00:00
|
|
|
|
|
|
|
@staticmethod
|
|
|
|
def get_ldap_dict_if_available(user_id):
|
|
|
|
try:
|
2020-06-04 18:59:36 +00:00
|
|
|
return LdapSchema().dump(LdapService().user_info(user_id))
|
2020-05-07 17:57:24 +00:00
|
|
|
except ApiError as ae:
|
|
|
|
app.logger.info(str(ae))
|
|
|
|
return {"error": str(ae)}
|
|
|
|
except LDAPSocketOpenError:
|
|
|
|
app.logger.info("Failed to connect to LDAP Server.")
|
|
|
|
return {}
|
Refactor the document details scripts. Now there is one script, it returns data in a consistent format, and has all the details required. The script is located in StudyInfo, with the argument documents. Make note that it returns a dictionary of ALL the documents, with a field to mark which ones are required according to the protocol builder. Others may become required if a workflow determines such, in which case the workflow will enforce this, and the document will have a count > 0, and additional details in a list of files within the document. I modified the XLS file to use lower case variable names, because it disturbed me, and we have to reference them frequently. Removed devious "as_object" variable on get_required_docs, so it behaves like the other methods all the time, and returns a dictionary. All the core business logic for finding the documents list now resides in the StudyService.
Because this changes the endpoint for all existing document details, I've modified all the test and static bpmn files to use the new format.
Shorting up the SponsorsList.xls file makes for slightly faster tests. seems senseless to load 5000 everytime we reset the data.
Tried to test all of this carefully in the test_study_details_documents.py test.
2020-04-29 19:08:11 +00:00
|
|
|
|
2020-04-29 14:21:24 +00:00
|
|
|
@staticmethod
|
|
|
|
def get_protocol(study_id):
|
|
|
|
"""Returns the study protocol, if it has been uploaded."""
|
|
|
|
file = db.session.query(FileModel)\
|
|
|
|
.filter_by(study_id=study_id)\
|
|
|
|
.filter_by(form_field_key='Study_Protocol_Document')\
|
|
|
|
.first()
|
|
|
|
|
|
|
|
return FileModelSchema().dump(file)
|
|
|
|
|
Created a "StudyService" and moved all complex logic around study manipulation out of the study api, and this service, as things were getting complicated. The Workflow Processor no longer creates the WorkflowModel, the study object handles that, and only passes the model into the workflow processor when it is ready to start the workflow.
Created a Study object (seperate from the StudyModel) that can cronstructed on request, and contains a different data structure than we store in the DB. This allows us to return underlying Categories and Workflows in a clean way.
Added a new status to workflows called "not_started", meaning we have not yet instantiated a processor or created a BPMN, they have no version yet and no stored data, just the possiblity of being started.
The Top Level Workflow or "Master" workflow is now a part of the sample data, and loaded at all times.
Removed the ability to "add a workflow to a study" and "remove a workflow from a study", a study contains all possible workflows by definition.
Example data no longer creates users or studies, it just creates the specs.
2020-03-30 12:00:16 +00:00
|
|
|
@staticmethod
|
2020-05-22 18:37:49 +00:00
|
|
|
def synch_with_protocol_builder_if_enabled(user):
|
Created a "StudyService" and moved all complex logic around study manipulation out of the study api, and this service, as things were getting complicated. The Workflow Processor no longer creates the WorkflowModel, the study object handles that, and only passes the model into the workflow processor when it is ready to start the workflow.
Created a Study object (seperate from the StudyModel) that can cronstructed on request, and contains a different data structure than we store in the DB. This allows us to return underlying Categories and Workflows in a clean way.
Added a new status to workflows called "not_started", meaning we have not yet instantiated a processor or created a BPMN, they have no version yet and no stored data, just the possiblity of being started.
The Top Level Workflow or "Master" workflow is now a part of the sample data, and loaded at all times.
Removed the ability to "add a workflow to a study" and "remove a workflow from a study", a study contains all possible workflows by definition.
Example data no longer creates users or studies, it just creates the specs.
2020-03-30 12:00:16 +00:00
|
|
|
"""Assures that the studies we have locally for the given user are
|
|
|
|
in sync with the studies available in protocol builder. """
|
2020-05-22 18:37:49 +00:00
|
|
|
|
2020-05-27 03:18:14 +00:00
|
|
|
if ProtocolBuilderService.is_enabled():
|
Created a "StudyService" and moved all complex logic around study manipulation out of the study api, and this service, as things were getting complicated. The Workflow Processor no longer creates the WorkflowModel, the study object handles that, and only passes the model into the workflow processor when it is ready to start the workflow.
Created a Study object (seperate from the StudyModel) that can cronstructed on request, and contains a different data structure than we store in the DB. This allows us to return underlying Categories and Workflows in a clean way.
Added a new status to workflows called "not_started", meaning we have not yet instantiated a processor or created a BPMN, they have no version yet and no stored data, just the possiblity of being started.
The Top Level Workflow or "Master" workflow is now a part of the sample data, and loaded at all times.
Removed the ability to "add a workflow to a study" and "remove a workflow from a study", a study contains all possible workflows by definition.
Example data no longer creates users or studies, it just creates the specs.
2020-03-30 12:00:16 +00:00
|
|
|
|
2020-05-27 03:18:14 +00:00
|
|
|
app.logger.info("The Protocol Builder is enabled. app.config['PB_ENABLED'] = " +
|
|
|
|
str(app.config['PB_ENABLED']))
|
|
|
|
|
|
|
|
# Get studies matching this user from Protocol Builder
|
|
|
|
pb_studies: List[ProtocolBuilderStudy] = ProtocolBuilderService.get_studies(user.uid)
|
|
|
|
|
|
|
|
# Get studies from the database
|
|
|
|
db_studies = session.query(StudyModel).filter_by(user_uid=user.uid).all()
|
|
|
|
|
|
|
|
# Update all studies from the protocol builder, create new studies as needed.
|
|
|
|
# Futher assures that every active study (that does exist in the protocol builder)
|
|
|
|
# has a reference to every available workflow (though some may not have started yet)
|
|
|
|
for pb_study in pb_studies:
|
|
|
|
db_study = next((s for s in db_studies if s.id == pb_study.STUDYID), None)
|
|
|
|
if not db_study:
|
|
|
|
db_study = StudyModel(id=pb_study.STUDYID)
|
|
|
|
session.add(db_study)
|
|
|
|
db_studies.append(db_study)
|
|
|
|
db_study.update_from_protocol_builder(pb_study)
|
|
|
|
StudyService._add_all_workflow_specs_to_study(db_study)
|
|
|
|
|
|
|
|
# Mark studies as inactive that are no longer in Protocol Builder
|
|
|
|
for study in db_studies:
|
|
|
|
pb_study = next((pbs for pbs in pb_studies if pbs.STUDYID == study.id), None)
|
|
|
|
if not pb_study:
|
2020-07-31 03:03:11 +00:00
|
|
|
study.status = StudyStatus.abandoned
|
2020-05-27 03:18:14 +00:00
|
|
|
|
|
|
|
db.session.commit()
|
Created a "StudyService" and moved all complex logic around study manipulation out of the study api, and this service, as things were getting complicated. The Workflow Processor no longer creates the WorkflowModel, the study object handles that, and only passes the model into the workflow processor when it is ready to start the workflow.
Created a Study object (seperate from the StudyModel) that can cronstructed on request, and contains a different data structure than we store in the DB. This allows us to return underlying Categories and Workflows in a clean way.
Added a new status to workflows called "not_started", meaning we have not yet instantiated a processor or created a BPMN, they have no version yet and no stored data, just the possiblity of being started.
The Top Level Workflow or "Master" workflow is now a part of the sample data, and loaded at all times.
Removed the ability to "add a workflow to a study" and "remove a workflow from a study", a study contains all possible workflows by definition.
Example data no longer creates users or studies, it just creates the specs.
2020-03-30 12:00:16 +00:00
|
|
|
|
|
|
|
@staticmethod
|
|
|
|
def __update_status_of_workflow_meta(workflow_metas, status):
|
|
|
|
# Update the status on each workflow
|
|
|
|
warnings = []
|
|
|
|
for wfm in workflow_metas:
|
|
|
|
if wfm.name in status.keys():
|
|
|
|
if not WorkflowState.has_value(status[wfm.name]):
|
|
|
|
warnings.append(ApiError("invalid_status",
|
|
|
|
"Workflow '%s' can not be set to '%s', should be one of %s" % (
|
|
|
|
wfm.name, status[wfm.name], ",".join(WorkflowState.list())
|
|
|
|
)))
|
|
|
|
else:
|
|
|
|
wfm.state = WorkflowState[status[wfm.name]]
|
|
|
|
else:
|
|
|
|
warnings.append(ApiError("missing_status", "No status specified for workflow %s" % wfm.name))
|
|
|
|
return warnings
|
|
|
|
|
|
|
|
@staticmethod
|
|
|
|
def __get_workflow_metas(study_id):
|
|
|
|
# Add in the Workflows for each category
|
2020-04-23 23:25:01 +00:00
|
|
|
workflow_models = db.session.query(WorkflowModel). \
|
|
|
|
join(WorkflowSpecModel). \
|
|
|
|
filter(WorkflowSpecModel.is_master_spec == False). \
|
|
|
|
filter(WorkflowModel.study_id == study_id). \
|
2020-03-30 18:01:57 +00:00
|
|
|
all()
|
Created a "StudyService" and moved all complex logic around study manipulation out of the study api, and this service, as things were getting complicated. The Workflow Processor no longer creates the WorkflowModel, the study object handles that, and only passes the model into the workflow processor when it is ready to start the workflow.
Created a Study object (seperate from the StudyModel) that can cronstructed on request, and contains a different data structure than we store in the DB. This allows us to return underlying Categories and Workflows in a clean way.
Added a new status to workflows called "not_started", meaning we have not yet instantiated a processor or created a BPMN, they have no version yet and no stored data, just the possiblity of being started.
The Top Level Workflow or "Master" workflow is now a part of the sample data, and loaded at all times.
Removed the ability to "add a workflow to a study" and "remove a workflow from a study", a study contains all possible workflows by definition.
Example data no longer creates users or studies, it just creates the specs.
2020-03-30 12:00:16 +00:00
|
|
|
workflow_metas = []
|
|
|
|
for workflow in workflow_models:
|
|
|
|
workflow_metas.append(WorkflowMetadata.from_workflow(workflow))
|
|
|
|
return workflow_metas
|
|
|
|
|
|
|
|
@staticmethod
|
|
|
|
def __get_study_status(study_model):
|
|
|
|
"""Uses the Top Level Workflow to calculate the status of the study, and it's
|
|
|
|
workflow models."""
|
|
|
|
master_specs = db.session.query(WorkflowSpecModel). \
|
|
|
|
filter_by(is_master_spec=True).all()
|
|
|
|
if len(master_specs) < 1:
|
|
|
|
raise ApiError("missing_master_spec", "No specifications are currently marked as the master spec.")
|
|
|
|
if len(master_specs) > 1:
|
|
|
|
raise ApiError("multiple_master_specs",
|
|
|
|
"There is more than one master specification, and I don't know what to do.")
|
|
|
|
|
2020-03-30 18:01:57 +00:00
|
|
|
return WorkflowProcessor.run_master_spec(master_specs[0], study_model)
|
Created a "StudyService" and moved all complex logic around study manipulation out of the study api, and this service, as things were getting complicated. The Workflow Processor no longer creates the WorkflowModel, the study object handles that, and only passes the model into the workflow processor when it is ready to start the workflow.
Created a Study object (seperate from the StudyModel) that can cronstructed on request, and contains a different data structure than we store in the DB. This allows us to return underlying Categories and Workflows in a clean way.
Added a new status to workflows called "not_started", meaning we have not yet instantiated a processor or created a BPMN, they have no version yet and no stored data, just the possiblity of being started.
The Top Level Workflow or "Master" workflow is now a part of the sample data, and loaded at all times.
Removed the ability to "add a workflow to a study" and "remove a workflow from a study", a study contains all possible workflows by definition.
Example data no longer creates users or studies, it just creates the specs.
2020-03-30 12:00:16 +00:00
|
|
|
|
|
|
|
@staticmethod
|
2020-05-25 16:29:05 +00:00
|
|
|
def _add_all_workflow_specs_to_study(study_model:StudyModel):
|
|
|
|
existing_models = session.query(WorkflowModel).filter(WorkflowModel.study == study_model).all()
|
Created a "StudyService" and moved all complex logic around study manipulation out of the study api, and this service, as things were getting complicated. The Workflow Processor no longer creates the WorkflowModel, the study object handles that, and only passes the model into the workflow processor when it is ready to start the workflow.
Created a Study object (seperate from the StudyModel) that can cronstructed on request, and contains a different data structure than we store in the DB. This allows us to return underlying Categories and Workflows in a clean way.
Added a new status to workflows called "not_started", meaning we have not yet instantiated a processor or created a BPMN, they have no version yet and no stored data, just the possiblity of being started.
The Top Level Workflow or "Master" workflow is now a part of the sample data, and loaded at all times.
Removed the ability to "add a workflow to a study" and "remove a workflow from a study", a study contains all possible workflows by definition.
Example data no longer creates users or studies, it just creates the specs.
2020-03-30 12:00:16 +00:00
|
|
|
existing_specs = list(m.workflow_spec_id for m in existing_models)
|
|
|
|
new_specs = session.query(WorkflowSpecModel). \
|
|
|
|
filter(WorkflowSpecModel.is_master_spec == False). \
|
|
|
|
filter(WorkflowSpecModel.id.notin_(existing_specs)). \
|
|
|
|
all()
|
|
|
|
errors = []
|
|
|
|
for workflow_spec in new_specs:
|
|
|
|
try:
|
2020-05-25 16:29:05 +00:00
|
|
|
StudyService._create_workflow_model(study_model, workflow_spec)
|
2020-05-30 19:37:04 +00:00
|
|
|
except WorkflowTaskExecException as wtee:
|
2020-06-03 19:03:22 +00:00
|
|
|
errors.append(ApiError.from_task("workflow_startup_exception", str(wtee), wtee.task))
|
Created a "StudyService" and moved all complex logic around study manipulation out of the study api, and this service, as things were getting complicated. The Workflow Processor no longer creates the WorkflowModel, the study object handles that, and only passes the model into the workflow processor when it is ready to start the workflow.
Created a Study object (seperate from the StudyModel) that can cronstructed on request, and contains a different data structure than we store in the DB. This allows us to return underlying Categories and Workflows in a clean way.
Added a new status to workflows called "not_started", meaning we have not yet instantiated a processor or created a BPMN, they have no version yet and no stored data, just the possiblity of being started.
The Top Level Workflow or "Master" workflow is now a part of the sample data, and loaded at all times.
Removed the ability to "add a workflow to a study" and "remove a workflow from a study", a study contains all possible workflows by definition.
Example data no longer creates users or studies, it just creates the specs.
2020-03-30 12:00:16 +00:00
|
|
|
except WorkflowException as we:
|
2020-06-03 19:03:22 +00:00
|
|
|
errors.append(ApiError.from_task_spec("workflow_startup_exception", str(we), we.sender))
|
Created a "StudyService" and moved all complex logic around study manipulation out of the study api, and this service, as things were getting complicated. The Workflow Processor no longer creates the WorkflowModel, the study object handles that, and only passes the model into the workflow processor when it is ready to start the workflow.
Created a Study object (seperate from the StudyModel) that can cronstructed on request, and contains a different data structure than we store in the DB. This allows us to return underlying Categories and Workflows in a clean way.
Added a new status to workflows called "not_started", meaning we have not yet instantiated a processor or created a BPMN, they have no version yet and no stored data, just the possiblity of being started.
The Top Level Workflow or "Master" workflow is now a part of the sample data, and loaded at all times.
Removed the ability to "add a workflow to a study" and "remove a workflow from a study", a study contains all possible workflows by definition.
Example data no longer creates users or studies, it just creates the specs.
2020-03-30 12:00:16 +00:00
|
|
|
return errors
|
|
|
|
|
|
|
|
@staticmethod
|
2020-05-25 16:29:05 +00:00
|
|
|
def _create_workflow_model(study: StudyModel, spec):
|
Created a "StudyService" and moved all complex logic around study manipulation out of the study api, and this service, as things were getting complicated. The Workflow Processor no longer creates the WorkflowModel, the study object handles that, and only passes the model into the workflow processor when it is ready to start the workflow.
Created a Study object (seperate from the StudyModel) that can cronstructed on request, and contains a different data structure than we store in the DB. This allows us to return underlying Categories and Workflows in a clean way.
Added a new status to workflows called "not_started", meaning we have not yet instantiated a processor or created a BPMN, they have no version yet and no stored data, just the possiblity of being started.
The Top Level Workflow or "Master" workflow is now a part of the sample data, and loaded at all times.
Removed the ability to "add a workflow to a study" and "remove a workflow from a study", a study contains all possible workflows by definition.
Example data no longer creates users or studies, it just creates the specs.
2020-03-30 12:00:16 +00:00
|
|
|
workflow_model = WorkflowModel(status=WorkflowStatus.not_started,
|
2020-05-25 16:29:05 +00:00
|
|
|
study=study,
|
2020-05-04 14:57:09 +00:00
|
|
|
workflow_spec_id=spec.id,
|
|
|
|
last_updated=datetime.now())
|
Created a "StudyService" and moved all complex logic around study manipulation out of the study api, and this service, as things were getting complicated. The Workflow Processor no longer creates the WorkflowModel, the study object handles that, and only passes the model into the workflow processor when it is ready to start the workflow.
Created a Study object (seperate from the StudyModel) that can cronstructed on request, and contains a different data structure than we store in the DB. This allows us to return underlying Categories and Workflows in a clean way.
Added a new status to workflows called "not_started", meaning we have not yet instantiated a processor or created a BPMN, they have no version yet and no stored data, just the possiblity of being started.
The Top Level Workflow or "Master" workflow is now a part of the sample data, and loaded at all times.
Removed the ability to "add a workflow to a study" and "remove a workflow from a study", a study contains all possible workflows by definition.
Example data no longer creates users or studies, it just creates the specs.
2020-03-30 12:00:16 +00:00
|
|
|
session.add(workflow_model)
|
|
|
|
session.commit()
|
|
|
|
return workflow_model
|