feat: automatically publish newly created flows

[jessicamcinchak]

This brings E2E helpers in sync in functionality introduced here: theopensystemslab/planx-new#4230

[RODO94]

My initial expectation was to destructure response into something like insert_flows_one: insertFlowResponse, but thinking about it more, do we keep response as is so it's easier to track variables in publishFlow lower down?

Crux of what I'm asking is, is it clearer to have:

  await publishFlow(client, {
    flow: {
      id: response.insert_flows_one.id,
      data: response.insert_flows_one.data,
    },
    publisherId: args.userId,
    summary: "Created flow",
  });

Or,

  await publishFlow(client, {
    flow: {
      id: insertFlowResponse.id,
      data: insertFlowResponse.data,
    },
    publisherId: args.userId,
    summary: "Created flow",
  });

[jessicamcinchak]

I simply extended the existing response pattern used throughout this file because I was only adding a single variable, either syntax would ultimately accomplish the same thing 👍

[RODO94]

Looks good to me, we're adding the Publish as part of creating a flow, with a summary note stating that. I'll look through the planx-new change as well.

I only had one comment on the variable naming.

[DafyddLlyr]

Something to take a look at here which might simplify a lot of the changes in theopensystemslab/planx-new#4230

One thing I'm not too sure of without a deep dive, is if there are places in e2e tests where the $admin client is creating flows as opposed to a user with a JWT (therefore no x-hasura-user-id session variable). If this is the case, we can insert using the $api role instead which relied on a JWT 👍

[DafyddLlyr]

We can also infer this from the JWT making the request - this might both avoid a lot of the associated cascading changes from adding this new argument, as well as ruling out an incorrect value being passed in.

If we just use "x-hasura-user-id" as a column preset, this will get read automatically from the JWT.

I'm pretty sure we can also toggle off access to the publisher_id column once this is configured as well to make sure no incorrect values get written in.

Docs: https://hasura.io/docs/2.0/auth/authorization/permissions/column-presets/

[jessicamcinchak]

This is a good shout - here's my understanding of how this is currently handled:

• e2e/tests/api-driven
  • globalHelpers all using $admin client (create user, create team, create flow) which is why we're manually passing around this userId
  • demo-workspace seems to be only exception to this which has uniquely defined/duplicated it's own createFlow mutaton. Strangely/incorrectly though, this is also the only variation of createFlow I've found which doesn't create an associated operation and therefore I haven't added initial publishing support either (the tests never cover either of these scenarios)
• e2e/tests/ui-driven
  • /helpers/context similarly all using $admin client (create user, create team, create flow, update settings/integrations, etc)
  • There is a generateAuthenticationToken method in this subdir to make a JWT, but the only reference I can find to this is when we call it once via await browserContext.addCookies() - the future actions like creating a flow, updating flow status etc are still ultimately routed through an $admin client afaik

Column preset definitely feels like the right direction of travel here, but also feels like an expansive piece of tech debt bigger than publishing alone ??

[DafyddLlyr]

Yeah similarly just been looking into this!

The column preset is a great solution for all real-life applications, but doesn't marry up to how we're creating flows in e2e environments (set up using $admin with no permissions, no user record associated via JWT).

I don't think making the userId param optional (for actual users) and conditionally reading argument or parsing from the JWT would make things any simpler - quite the opposite.

Agreed - this is a nice direction but a bigger change than I anticipated - this is a good route for now for sure ✅