feat: setup UserStore and basic visual feedback throughout editor based on access

[jessicamcinchak]

Changes

• Adds a UserStore with simple state management getters & setters for working with users & their roles within all authenticated routes
• Adds visual feedback throughout the editor UI to indicate if you have edit- or view-access for that team (this is crude and I'm not a designer! but hopefully gives us some starting ideas to improve on now 🙂)

Visual feedback examples

Teams

• Shows an icon next to each team to indicate edit- (:pen:) or view- (:eye:) access (in the future, we may want to think about ordering so edit-access is at the top etc)
  

Team

• Shows an icon in the team header to indicate edit- or view-access (we only restrict at team-level right now, not flows)
• If view-access, hides the copy/move/rename/delete menu & the "add a new service" button at the bottom of the list of services
• If edit-access, all options display as "normal"
  

Flow

• If view-access, disables the "check for changes to publish" button
• If view-access, hides all <Hanger /> points in the graph which makes it impossible to move, add or clone nodes (in the UI at least, not the actual operations table!)
• If view-access, I can still navigate through external portals, and that external portal flow loads correctly depending on my permissions to its' team
• If edit-access, all options display as "normal"
• It shows an icon next to the flow name in the header regardless of access
• It shows my real initial (!) regardless of access
  

Node

• If view-access, disables the delete/make unique/update buttons in the node dialog. You can still close using the upper "X" or clicking outside
• If view-access, disables the "image upload" icon preventing new images from being uploaded and disables the "remove" item in the menu of existing uploaded images
• If view access, disables the "add new", "drag/re-order" and "remove" icons for list options
• If view access, inputs are not disabled to allow easier copy + paste, but no changes will persist or be written to the DB
  

** I learned our original hypothesis about not connecting to ShareDB altogether, rather than restricting per operation method, doesn't actually work very well here because the connect & connectTo Editor store methods are actually responsible for loading the whole flow - so if we don't proceed with the connection, it just shows an empty graph!

Open questions / future improvements

• Where should the TeamStore be initiated ideally? For now, I often rely on window.location.pathname to get the teamSlug instead (which works totally fine, but doesn't feel the cleanest and assumes the editor will never be hosted at a custom subdomain!)
• I haven't touched global settings or settings pages yet
• How to consistently show user initial menu across teams, team and flow pages? It's inconsistent for me now on teams and team (eg sometimes shows if I'm navigating back from a flow, but not on initial load)
• TESTS - there's a few that got skipped here because we'll need to figure out how to mock an authenticated user with platform admin permissions for buttons to be visible etc

[github-actions]

Removed vultr server and associated DNS entries

[jessicamcinchak]

Implement user permissions in frontend

[DafyddLlyr]

A few comments on PR, no show stoppers! Looking great and feels very solid 👏 I'm sure Alastair and Ian will have some design thoughts but that's 100% a separate issue.

A few unit tests for maybe some components and UserStore methods would probably be wise as a next step 👍

Hitting a few issues small on the Pizza mainly related to the teamStore not being populated. I think this is related to an issue we've discussed before around how teams are handled within the editor (window.api.getState().getTeam() is perfect in /preview and /unpublished but inconsistent in the Editor as you've flagged in this PR.

I think we'll need to resolve this before going for a prod deploy - I'll queue on up just now so we can get the code changes from already merged to main pushed forward in the meantime.

[DafyddLlyr]

Just realised in the demo...

• We need to disable drag drop in the modal
• We need to hide "delete" buttons in modal

I'm not exactly sure when the "update" happens - I think it's on save of the modal but juuuuust in case? And I guess it's about expected behaviour also.

[jessicamcinchak]

so this is a notable change! moveNode is the only graph method that called this shared store method, which causes the window to reload, the user to no longer be set, and therefore the flow incorrectly reloads as if it's now view-only rather than edit-access as intended.

from what I can tell, resetPreview is intended to be called outside the Editor based on the variables it's setting, and in testing I can't see any in-editor issues with removing it (the operation is still successful, the flow order after move persists as expected, etc). But please do test this!