Edit workflow request when queried depending on role or project setting

[mcbouslog]

Temporary Alternative: see branch disable-test-workflow

Fixes broken Test Workflow button from workflow editor in lab.

If a workflow query in url and admin/owner/collaborator remove active: true from workflow request to allow viewing of inactive workflow, i.e. via Test Workflow button from lab.

If a workflow query in url and project settings allow workflow queries, try to get requested workflow, but if inactive then remove query and proceed through other workflow determining steps.

Review Checklist

• Does it work in all major browsers: Firefox, Chrome, Edge, Safari?
• Does it work on mobile?
• Can you rm -rf node_modules/ && npm install and app works as expected?
• Did you deploy a staging branch? - https://test-workflow-fix.pfe-preview.zooniverse.org/
• Did you get any type checking errors from Babel Typecheck

Optional

• If it's a new component, is it in ES6? Is it clear of warnings from ESLint?
• Have you replaced any ChangeListener or PromiseRenderer components with code that updates component state?
• If changes are made to the classifier, does the dev classifier still work?
• Have you added in flow type annotations?

[mcbouslog]

On staging:
as collaborator, admin mode off or on: Test Workflow button in inactive workflow works

On production (https://test-workflow-fix.pfe-preview.zooniverse.org/projects/zooniverse/notes-from-nature/classify?env=production&workflow=3758):
with admin mode on: Test Workflow button in inactive workflow works
with admin mode off, just as collaborator: Test Workflow button in inactive workflow doesn't work, unsure why (issue with staging branch pointing to production, or maybe checkUserRoles is returning false before properly completing)

[mcbouslog]

Ideally wouldn't update user workflow preference if accessing workflow vie workflow query and admin/owner/collab, but if I remove this I think an infinite loop is triggered in componentWillUpdate because the preferences don't match, that keeps requesting the same workflow from API.

[srallen]

I think we still want this behavior even if admin/owner/collab because that user might just be wanting to classify on their own project and storing the workflow id in the prefs means it'll load up the correctly selected workflow if they browse between talk and back, etc. If they revisit w/o the query param for the workflow, the behavior will clear out the workflow from their prefs if inactive.

[srallen]

I'm not seeing an issue with the workflow query param for a project that I'm a collab on in production. What's the specific error you're seeing?

[srallen]

This line will still need an existential check on the user: user?.id. Trying the workflow query param when logged out is broken otherwise.

[mcbouslog]

Just as a collaborator when I try https://test-workflow-fix.pfe-preview.zooniverse.org/projects/zooniverse/notes-from-nature/classify?env=production&workflow=3758 it goes through the second getSelectedWorkflow condition, like I'm a regular user, expectedly can't find the workflow (because it's only looking for active: true ones), then truncates the url and loads a random workflow.

I tried (Test Workflow button on inactive workflow as a collaborator) on a different production project and it did work though, so it must be NfN related, though not sure it's due to related project setting or size of NfN.

[mcbouslog]

Turns out it was that there are more than 20, the default page_size, project roles for NfN, and mine was not in ones returned, so thought I was regular volunteer and putting me in second conditional. I think I've updated with a fix.

[camallen]

should we just allow filtering of the project roles with the user_id instead of fetching pages of data and looking through it? Possibly related to zooniverse/panoptes#1575

[mcbouslog]

Removed unnecessary page_size increase. By including user_id in the request an increased page_size isn't necessary.

If user_id is undefined all project roles are returned, which in NfN's case would be 20 roles out of 30 without a change to the default page_size, but that's fine because this is a situation where the user isn't signed in, so whether there are 20 or all roles returned there will never be a matching role to no user.

@camallen - let me know if I've misinterpreted, but I think this addresses your comment?

[mcbouslog]

I plan to add a conditional to check if user is defined before even requesting projectRoles, so if there's no user the request is never made, and see how that works, or if there are any other requests that could be refactored similarly, but unsure if that will work, thinking about it from memory not actually looking at the code at the moment.

[srallen]

@mcbouslog having the project roles in the project controller state is useful whether there is a logged in user or not. My intention of requesting it as an include with the project was to eventually eliminate a few places where it is redundantly called on other project pages, such as the team listing on the about pages.

Most projects probably don't have more than 20 roles on them. NfN is again probably unique in this. Increasing the page size is a sufficient interim fix. We can refactor once improvements are made, like querying with user id or project role name to determine if the logged in user is a collab.

[mcbouslog]

@srallen - makes sense and sounds good to me, I added back the page_size: 50 and removed the user_id from the request. I left the project_roles in the project request include, as that sounds like part of the long-term intent.

I'm sure intentional, but thought I'd note the project.links for subject_sets and workflows appear to have all related resource IDs, but project_roles only has the usual API default size of 20. If project.links.project_roles also had all, I think the project_roles request as currently written which requests an array of project role IDs would work as well, without the page_size: 50.

[camallen]

Understood @srallen - page_size limit increase works (for a while) if you need the resources elsewhere. The lab page could access check could use the specific filter query for the logged in user but that can come later.