draft: Adding Flow Name to Editor Files

[RODO94]

What does this PR do?

This Pull Request (PR) integrates changes to the data model regarding flows where we have added a name column to the database. This is a non-slug version of a flow name which should be displayed to users across the editor pages.

Info on Changes

For queries and mutations looking to edit a flow or retrieve a flow, I have added name as a record to retrieve.

For validation logic, I have changed the Rename mutation to use name instead of slug for comparison check.

-  if(newName && slugify(newName) !== flow.slug)
+  if(newName && newName !== flow.name)

This will make it easier for users to make capitalisation changes

This means that if you add This is planning for england but you want to change it to This is planning for England, you won't receive an error for duplicate slug

Important Info

This PR is a copy of #3219 but I got a bit tangled in rebasing so I have made a cleaner branch and cherry picked commits.

[github-actions]

Removed vultr server and associated DNS entries

[jessicamcinchak]

Changes looking good here, just a couple last details & tests to sort out !

re failing e2e tests: looks like they're failing on the "Section" component, which currently displays the flowName - so we'll want to ensure that's still getting set properly!

Try testing this locally by adding a Section component to any flow, then ensuring it displays as expected with flow name header across all routes: /draft, /preview, /published. If you can't spot any bugs locally, then we'll keep investigating e2e - but my best guess currently is that one of these routes is failing to read name!

[jessicamcinchak]

Question - I'm not sure I understand why this file or query has to change at all? Can we still find/load a flow based on it's slug?

If the issue is that flowName is not being set properly, and that's why this query needs to additionally return name now, then I think this is a good example where we want to call useStore.getState().setFlowSlug() & useStore.getState().setFlowName() individually, rather than this full setFlow which requires id & data.

fetchDraftFlattenedFlowData is an expensive call and I think we want to avoid it on a Team route like this!

[RODO94]

Yeah we can definitely run everything individually, the only reason I added the fetchDraftFlattenedFlowData was because for SetFlow to work, it needed the flow data in a certain form which wasn't available.

I'll switch it back to individually setting the state.

[RODO94]

For the original comment regarding the Section component

I have added it and the flowName is shown correctly. Looks like it just pulls it in from the Global Store as flowName so I couldn't track anywhere for it going wrong.

I'll make the changes mentioned above for fetchDraftFlattenedFlowData and see if this fixes the e2e testing

[jessicamcinchak]

Looking really great - but noticed one thing on the pizza we'll need to adddress still before merging please!

From the list of "My services" within a team, there's a "Copy" action in the menu next to each flow - this still works, but is failing to assign a name to the flow, meaning that it appears in the list without a title ! I would expect a copied flow to have the same name as the original with "copy" appended to the end (same as existing slug behavior).

These might be good places to start in the code:

• flows/copyFlow/ module in the API: https://github.com/theopensystemslab/planx-new/blob/main/api.planx.uk/modules/flows/copyFlow/service.ts
• And specifically this mutation: https://github.com/theopensystemslab/planx-new/blob/main/api.planx.uk/helpers.ts#L61-L103 (only called by copyFlow)

[jessicamcinchak]

All working as expected on pizza now, let's merge 🙌

[RODO94]

Issue with Flow Name not Appearing

Looking into Flow Names not appearing on Pizza but on my local machine points to new flows being made after the point I sync'd the data from Hasura?

Would mean it's not a bug and more a feature, would this make sense @jessicamcinchak ?

[jessicamcinchak]

Looking into Flow Names not appearing on Pizza but on my local machine points to new flows being made after the point I sync'd the data from Hasura?

Yep, I think you're spot on here - there's a couple things going on:

• The migration already ran on production once, so new flows only have a slug still
  • When the pizza was created fresh this afternoon it pulled down the latest prod data, so it picked up these new name-less flows
• flows.name is not a required field (maybe it should be?)

I think we definitely want to clear this up before merging - let's talk through options in the morning - may be as simple as manually re-running the SQL migration to update any null flow names in sync with the code merge?