Restrict stage visibility based on membership

[3mcd]

Motivation

So users only see stages they have permission to view.

Requirements

Modify stage-related queries so that:

• Community contributors can only see stages they have been added to directly or via groups.
• Community editors and admins can always see all stages.

If a user does not have the ability to see any stages, the link to "Workflows" in the side nav should not appear.

Acceptance Criteria

• Uses functions implemented in Write function(s) that query pub or stage privilege #671 to determine if the user has the viewStage capability for each rendered stage.
• End-to-end tests that assert that stages on the workflows page are only visible when the above requirements are met.

[kalilsn]

If a user does not have the ability to see any stages, the link to "Workflows" in the side nav should not appear.

This might be a little challenging to do efficiently with the current setup and may require a new (pretty simple) query either way.

[3mcd]

@kalilsn I agree that the requirement to show/hide the Workflows link adds a bit of overhead (one query per page load) for little gain. Instead I think we could always show the link and just put an informative message on the Workflows page if no stages are accessible to the user. Thoughts @gabestein ?

[allisonking]

this would involve the following, though I'd love confirmation that this sounds on the right track:

• modifying this query to filter by only stages the user has the viewStage capability for

  platform/core/lib/server/stages.ts

  Lines 52 to 103 in 76f44f2

  	export const getStages = ({ communityId, stageId }: CommunityStageProps) =>
  	autoCache(
  	db
  	.selectFrom("stages")
  	.where("communityId", "=", communityId)
  	.$if(Boolean(stageId), (qb) => qb.where("stages.id", "=", stageId!))
  	.select((eb) => [
  	jsonArrayFrom(
  	eb
  	.selectFrom("move_constraint")
  	.whereRef("move_constraint.stageId", "=", "stages.id")
  	.innerJoin("stages as s", "s.id", "move_constraint.destinationId")
  	.select(["s.id", "s.name"])
  	).as("moveConstraints"),
  	jsonArrayFrom(
  	eb
  	.selectFrom("move_constraint")
  	.whereRef("move_constraint.destinationId", "=", "stages.id")
  	.innerJoin("stages as s", "s.id", "move_constraint.stageId")
  	.select(["s.id", "s.name"])
  	).as("moveConstraintSources"),
  	eb
  	.selectFrom("PubsInStages")
  	.select((eb) =>
  	eb.fn
  	.count<number>("PubsInStages.pubId")
  	.filterWhereRef("PubsInStages.stageId", "=", "stages.id")
  	.as("pubsCount")
  	)
  	.as("pubsCount"),
  	// TODO: needs to be fancier and include member groups
  	eb
  	.selectFrom("stage_memberships")
  	.select((eb) =>
  	eb.fn
  	.count("stage_memberships.userId")
  	.filterWhereRef("stage_memberships.stageId", "=", "stages.id")
  	.as("memberCount")
  	)
  	.as("memberCount"),
  	eb
  	.selectFrom("action_instances")
  	.whereRef("action_instances.stageId", "=", "stages.id")
  	.select((eb) =>
  	eb.fn.count<number>("action_instances.id").as("actionInstancesCount")
  	)
  	.as("actionInstancesCount"),
  	])
  	.selectAll("stages")
  	.orderBy("order asc")
  	);

• if the query returns an empty list in the Workflows page here, then render a message that there are no accessible stages

  platform/core/app/c/[communitySlug]/stages/manage/page.tsx

  Line 69 in 76f44f2

  const stages = await getStages({ communityId: community.id }).execute();

• will returning only some stages mess with the graph layout? maybe it'll just work?

[gabestein]

will returning only some stages mess with the graph layout? maybe it'll just work

I think this is a community editor- and admin-only view anyway, so we can probably just not render it if you don't have access to view all stages? We will eventually want to support a case where you can be just a stage editor, but I don't think we'll render the workflows page for you — just a stage settings page.