Engaging Crowds: Allow completed workflows to be fetched by ID #2580
Conversation
eatyourgreens
force-pushed
the
fetch-completed-workflows
branch
from
2cea1ca to
f50c48a
Compare
When a workflow ID is specified in a page URL, fetch that workflow even if it's been completed.
eatyourgreens
force-pushed
the
fetch-completed-workflows
branch
from
96bd299 to
5534905
Compare
There was a problem hiding this comment.
PR Review
Package: lib-classifier
This PR modifies the Classify page's behaviour in regards to 100% completed Workflows
Current behaviour: if WF 1234 is 100% classified (completed), accessing the WF URL (e.g. /projects/foo/bar/classify/workflow/1234) causes the workflow to not load properly.
- for a grouped Workflow with selectable Subject Sets, instead of the SSet selection menu, the Classify page loads with no tasks and no Subjects.
- ❔ (Unknown: not sure what happens for completed non-grouped Workflows, but presumably the same.)
New behaviour: if WF 1234 is 100% classified, accessing the WF URL causes the Workflow to load properly.
- for a grouped Workflow, the SSet selection menu opens as expected.
- ❔ (Untested: for completed non-grouped workflows, presumable the Classify page loads as normal.)
Consideration: is there any reason why we wouldn't want to allow users access to an active but completed workflow?
Answer: not really, no? There's no reason to not allow access to an active WF.
- Our main concerns are 1. we don't allow bad classifications to be submitted (won't be the case here), and 2. we don't waste volunteer's time. (see below)
- If a WF has selectable Subject Sets, the SSet selection menu will clearly show that all selectable subject sets are completed, so volunteers won't need to waste their time.
- If a WF has no selectable SSets, the Classify interface shows immediately, and this will indicate that "this Subject is finished", again so volunteers won't need to waste their time.
Testing
Tested on localhost and on production, with the HMS NHS project, using macOS + Chrome 96
- Current behaviour was confirmed (on production) by selecting an active but completed workflow, WF 18611: https://www.zooniverse.org/projects/msalmon/hms-nhs-the-nautical-health-service/classify/workflow/18611
- As expected, the WF wouldn't show the SSet selection menu.
- New behaviour was confirmed (on local) by selecting the SAME active but completed workflow, WF 18611: https://local.zooniverse.org:3000/projects/msalmon/hms-nhs-the-nautical-health-service/classify/workflow/18611?env=production
- As expected, the SSet selection menu appears, with all visibly complete/finished Subject Sets
- As expected, the SSet selection menu appears, with all visibly complete/finished Subject Sets
Dev Notes
- Check out ADR 34 for notes on the removal of explicit default workflows.
Status
LGTM 👍
| @@ -67,13 +84,34 @@ function orderWorkflows(workflows, order) { | |||
| return workflowsInOrder | |||
| } | |||
|
|
|||
| async function fetchWorkflowsHelper(language = 'en', activeWorkflows, defaultWorkflow, workflowOrder = [], env) { | |||
There was a problem hiding this comment.
Making a note that we're removing the concept of explicit default workflows here, (i.e. project.default_workflow) which is in line with ADR 34
When a workflow ID is specified in a page URL, fetch that workflow even if it's been completed.
Try it out with a finished workflow from HMS NHS:
https://local.zooniverse.org:3000/projects/msalmon/hms-nhs-the-nautical-health-service/classify/workflow/18618?env=production
This fixes a bug where returning to a completed workflow, eg. by bookmarking the URL, takes you to a blank page with an empty classifier, because the Classify page doesn't load completed workflows.
https://www.zooniverse.org/projects/msalmon/hms-nhs-the-nautical-health-service/classify/workflow/18618
Package:
app-project
Review Checklist
General
Components
Apps
yarn panic && yarn bootstrapordocker-compose up --buildand app works as expected?Publishing
Post-merging