-
Notifications
You must be signed in to change notification settings - Fork 1
[Do not merge] User based access #3
base: main
Are you sure you want to change the base?
Conversation
2720d63
to
4ada9d5
Compare
Designer publishes to the runner stillThe designer currently publishes to the runner frequently using this function. Likely we'll want to move away from the designer doing any publishing, and move to there being a separate form management appUpdateAs of this commit these calls have been removed. In the future there will need to be a layer for form management, although this could be moved out of the designer (Whether or not that's something ideal to contribute back to the XGov Designer is up for discussion on if it would benefit the users of the xgov tools or not) |
Hey @danielburnley - it'd be good to chat about this if possible. A few users from the community have asked about this, and I haven't had time to implement myself. My idea of a first slice was this too ☝️. With this implemented you can get rid of the duplication we do when a user selects an existing form. We originally did this with the intention of implementing some sort of RBAC (but never got round to it) - but to prevent users editing and overwriting someone else's form, we chose to duplicate. Anyway, this looks good so far, I'd like to add it as an option to the open source repo some time so features you're developing are available to other depts (DIT, DFE, NHS, and Dave from GDS) 🙏 Here's the slack workspace with other community members (and me). out of interest - how much development will GDS be doing on this? are you still spiking around? |
Hey @jenbutongit 👋🏻 I've joined the slack 🎉 thanks for the link! Ahhhh that's what the duplication is for, I did wonder if it was something like that - that makes sense. If I get the chance I'd be interested in trying to clean this up a little at some point and actually write some tests around the API persistence at a minimum - at the moment i'd feel it's a bit lacking in at least the tests + a bit of documentation of "what the API should implement", but i'd be down with at least starting something off if you felt it would be useful 🎉 At the moment we're currently doing a couple spikes to assess how easy it'd be to use the designer either in part/in full, and also to facilitate a couple other spikes (this one for example helps us experiment connecting to a couple other login providers that are in use already so we don't have to write Yet Another Authentication System 😅 ) Feel free to DM me on slack if you want! |
Adding user based access
By using the forms api prototype this branch explores what would be required to add user based access to the digital form builder.
This will describe the current state at opening the PR, with comments describing any updates that are done going forward
Persistence layer
The forms API prototype acts as the new persistence layer option alongside the existing options. This gives the ability to do user based access as you can send a user token alongside any request to get/submit for a particular user.
Designer
API Persistence service
Adds a new persistence service that uses the forms API, replicating the endpoints that were previously on the runner. This also adds some additional methods to perform actions "by user"
Selecting a user
As an initial pass - there is a small user picker displayed at the top of the page that lets you "login" to the user you want.
This works by setting a cookie to define which user you are logged in as, which can then be passed to the API persistence service.
Runner
Forms API integration
Pulls data from the Forms API instead of using locally stored forms files. As the API doesn't currently have a concept of "publishing", this can only get the forms saved when no user is created.