Closed elrayle closed 7 years ago
Since workflows aren't picked up unless manually loaded into the DB, no workflow is the default behavior. Do we need this ticket?
It would be better if we could always depend on a workflow and never had to do a null check.
@scholarworks @jcoyne Should this PR include then some way to automatically load the default workflow, e.g., when a curation concern is created?
@jcoyne @mjgiarlo - confirmed that a null workflow (i.e., has the work type name but zero actions) throws an error on load. I do have a very basic single step ("submitting") workflow outlined that may be sufficient.
If this looks OK, I'll do a PR. Otherwise, I can keep cleaning it up.
@jcoyne @scholarworks Fair warning: I care more about names than I should, sometimes. ;)
My only questions about your json are related to naming. The names that are conventionally used for states in Sipity are words or phrases that can complete the sentence "The work is ____." So how about something like "new" as the initial state and "deposited" as the final state? If those are the states, I might also rename the "complete" action to "deposit" it to align with the state names, and rename the role to "depositing". So like:
{
"work_types": [
{
"name": "<%= file_name %>",
"actions": [{
"name": "deposit",
"from_states": [{"names": ["new"], "roles": ["depositing"]}],
"transition_to": "deposited",
"notifications": [
{
"notification_type": "email",
"name": "confirmation_of_submitted_to_ulra_committee",
"to": ["creating_user"],
"cc": ["advising"]
}
],
"methods": [
"CurationConcerns::Workflow::ActivateObject"
]
}]
}
]
}
@jcoyne @scholarworks My other question (more for @jcoyne and @vantuyls) is whether we should keep the work_types
jazz in there given other discussions about moving away from work types as a way to assign and manage workflows.
Thanks, @scholarworks!
Yeah, we should remove work_types
and we should add a label
and description
field. As far as what you call the states, I DGAF, @jeremyf seemed to have strong feelings though.
I suspect my suggested names are @jeremyf -friendly, but I'll let him be the judge! :+1: to your suggested changes, @jcoyne.
@mjgiarlo I have no strong feelings on names, so I totally welcome these.
@jcoyne - at what level will the label
and description
field go? Same as name
?
@scholarworks yes, at top level of the workflow.
Something like this:
{
"label": "Default Workflow",
"description": "A single submission step, default workflow",
"actions": [{
"name": "deposit",
"from_states": [{"names": ["new"], "roles": ["depositing"]}],
"transition_to": "deposited",
"notifications": [{
"notification_type": "email",
"name": "confirmation_of_submitted_to_ulra_committee",
"to": ["creating_user"],
"cc": ["advising"]
}],
"methods": [
"CurationConcerns::Workflow::ActivateObject"
]
}]
}
@scholarworks We still need a "name"
at the top level, and I think we should keep the "work_types"
too, but change it to something like "workflows"
{
"workflows": [
{
"name": "default",
"label": "Default Workflow",
"description": "A single submission step, default workflow",
"actions": [{
"name": "deposit",
"from_states": [{"names": ["new"], "roles": ["depositing"]}],
"transition_to": "deposited",
"methods": [
"CurationConcerns::Workflow::ActivateObject"
]
}]
}
]
}
@mjgiarlo shoudn't the from_states
for deposit be []
? See https://github.com/projecthydra/curation_concerns/blob/82b079eac450f5d7317d941dfdc880fc60f7bd0d/lib/generators/curation_concerns/templates/workflow.json.erb#L10
@jcoyne yep. just fixed that, in fact, after I ran into errors. ;)
Descriptive summary
Define workflow that can be used as default for current process used to create a New Work.
Expected behavior
When on the New Work UI, user can upload, set metadata, set relationships, and save without having to transition through states.
New Work