Skip to content

Latest commit

 

History

History
51 lines (30 loc) · 2.93 KB

adr-18.md

File metadata and controls

51 lines (30 loc) · 2.93 KB

ADR 18: Workflow routing

Created: September 4, 2019

Context

On PFE, there are a couple of different ways workflows are routed:

  • Navigating to /classify, the user sees either the default workflow for that project, a random active workflow, or the workflow stored in project preferences for logged-in volunteers.
  • Navigating to /classify?workflow=[workflow_id] shows the workflow determined by the query parameter when the "Use workflow query" feature is enabled for the project, or if the user has the correct role (owner, collaborator, tester, or admin).

This is not optimal for several reasons. Users cannot bookmark specific workflows unless they use the query parameter; there can be uncertainty over which actual workflow is being shown (particularly as the workflow name isn't shown in the UI); different workflows can be shown at the same URL at different times; and ultimately, workflows are static resources that should be routed to - that's what URLs are for.

Additionally, we currently have a requirement for CSSI CitSci to be able to route to specific subjects. It's conceivable that a project will have a requirement for routing to a specific subject set linked to a workflow as well.

Decision

We adopt the following URL structure:

/projects/[owner]/[project]/classify/workflow/:workflow-id/subject-set/:subject-set-id/subject/:subject-id

This would be facilitated by the dynamic routing feature in Next.js 9 (see #1071).

Workflow links from the home page would route directly to their workflow-specific URLs.

/classify behaviour

When navigating to /classify, the page should redirect the user to the correct workflow URL in the following priority:

  1. Workflow ID set in user project preferences by the user
  2. Workflow ID set in user project preferences by the project
  3. Project default workflow
  4. Random active selection

The new URL that we redirect the user to should replace the entry for /classify in the browser history.

Error handling

When a user is unable to view a workflow at a given URL, we should provide an error page at that URL. Next.js allows you to provide a response code in getInitialProps, which we can use to tailor the message we show on a custom error component, so for non-existent workflows, 404; incorrect permissions get a 401/403 (depending on login status) etc.

Status

Accepted

Consequences

  • /classify will still have different effects depending on the user, but solely in terms of redirects rather than content.
  • We'll have to start storing at least portions of the MST state object in the browser, in order to allow for users to navigate back and forth between Talk and the classifier transparently.
  • Workflow access restriction can be managed at the workflow component file level.