Maps response: resp.map((obj) => { GET obj.id from backend })
Assumes each obj is a Policy entity, set an internal property: policy._type = obj.type
obj.type === (funder|institution)
Submission workflow, policies step:
Clear any previously set submission.effectivePolicies so that this step can set it again 😞
Invokes PolicyService#getPolicies
Sets route model.policies to result
Renders WorkflowPolicies component
WorkflowPolicies component doesn't do much. Renders a list of PolicyCard components
PolicyCard
Identifies a Policy as the JHU policy by matching title 😔
Slightly tweaks copy for JHU policy specifically, "Expects deposit ..." as opposed to "Requires depost ..." otherwise
Shouldn't this just be the Policy.description?
Identifies PMC related policy by matching policy.repositories[].repositoryKey === pmc :: matches repositoryKey to known enum value of pmc
For PMC related policies, determines the submission's journal as "Method A" or not
Method A journals automatically submit to PMC on behalf of author
Otherwise user chooses whether or not to submit to PMC through PASS
Does this require the fetching of Policies to be done in the backend?
No it seems like we could gather the Policies in the UI:
submission.grants.primaryFunder[].policy
submission.grants.directFunder[].policy
Match user affiliation to institutional policy
If we had business logic driving policy selection, then it would be a good idea to have that done in the backend. For example, if we were to automatically match a submission to a Method A journal, we know the submission will already meet PMC's policy requirements, as the journal will / already has submitted the article.
However, some user input may be required in some cases. For non-MethodA journals, a user may have already had the manuscript submitted to PMC or another valid repository. How should PASS be informed of this at this point in the submission? This input is used to set the effectivePolicies property on the Submission. Should we eliminate this property and assume all policies are applicable, then in the Repositories step update the user input appropriately to let the user decide where to route the submission?
Policy Service in the UI
PolicyService#getPolicies:resp.map((obj) => { GET obj.id from backend })objis a Policy entity, set an internal property:policy._type = obj.typeobj.type === (funder|institution)Submission workflow, policies step:
submission.effectivePoliciesso that this step can set it again 😞PolicyService#getPoliciesmodel.policiesto resultWorkflowPoliciescomponentWorkflowPolicies component doesn't do much. Renders a list of PolicyCard components
PolicyCardPolicy.description?policy.repositories[].repositoryKey === pmc:: matchesrepositoryKeyto known enum value ofpmcDoes this require the fetching of Policies to be done in the backend?
No it seems like we could gather the Policies in the UI:
submission.grants.primaryFunder[].policysubmission.grants.directFunder[].policyIf we had business logic driving policy selection, then it would be a good idea to have that done in the backend. For example, if we were to automatically match a submission to a Method A journal, we know the submission will already meet PMC's policy requirements, as the journal will / already has submitted the article.
However, some user input may be required in some cases. For non-MethodA journals, a user may have already had the manuscript submitted to PMC or another valid repository. How should PASS be informed of this at this point in the submission? This input is used to set the
effectivePoliciesproperty on the Submission. Should we eliminate this property and assume all policies are applicable, then in the Repositories step update the user input appropriately to let the user decide where to route the submission?