Feature Request: RBAC support in the PuckConfig

[mkilpatrick]

As an extension of #255, a nice feature would be to allow role-based controls in the PuckConfig. An example would describe it best.

A developer defines a bunch of components that an admin (the person who drags components) can use to create their webpage. This is the standard Puck flow today. The admin is actually a super user that has controls to lock or define specific things that a lower user (let's call them "individual") can/can't do.

Component Locking
The admin drags some components on the page, such as a header/footer. The admin can set the props and additionally lock those components. When the individual logs in, they can drag other components on to the page that the admin has already set up but they cannot do anything with the header/footer. They can't add/remove or even edit props of those locked components. Those components has been locked in entirety by the admin. This is accomplished today by the developer by coding in the header/footer and not exposing it as a component. This goes one step further where the component is exposed where the admin can use it but then lock it out from other roles.

Prop Locking
Similar to above except that the admin sets some props and locks them, leaving other props available. The individual can now only modify the unlocked props of that component. In this scenario the props are only locked for the component dragged onto the page, so it's this specific component instance that has locked props. If the admin drags a CTA component onto the page and locks 2/3 of the props then the individual can only modify the other 1/3 props. BUT if the individual adds a second CTA to the page, they have access to all of the props.

Component Exposure
This is sort of similar to component locking, however in that scenario the admin drags the component onto the page and locks out the individual from making any edits to it. For exposure, this means that the admin can allow/disallow components from being seen/draggable at all to the individual. Why would we want this? Well, a developer goes and adds 100 different components. The admin comes in and decides that they only want their individual users to be able to use a handful of that library of components. The admin disallows or allows the components from the left navigation component list.

Prop Exposure
This is a combo of prop locking and component exposure. The admin can lock props at the component level from the left sidebar. Obviously some sort of new UI would be required. Maybe a modal of some sort for these interactions. Since props are locked at the component level and not just the component instance, when an individual drags a component onto the page they can only edit the non-locked props.

Default Props
For prop exposure to really have much value, the admin should be able to define default props of components (again at the component level and not instance level).

Component Count
The admin (developer too) can specify the number of times a component can be used. If set to 1 then the component can only have a single instance ever used.

All of these features aim to allow businesses to use a developer to initially set things up (or even pull from a good puck component library), but after that put most of the configuration and controls in the hands of an admin who is not a developer. The admin defines the controls that their users can actually turn the knobs on. This is basically a franchise-like RBAC flow. Conglomerate X has their devs create a component library. Their marketers come in and create some different templates in the Puck UI. The marketers know the X brand and set things up accordingly. The header/footer must fit their corporate design. They do want their franchisees to be able to customize a few things on each franchise landing page though, so they allow them to add a few additional components on the page and move a few things around. The franchisees can go in and do their thing but they can't stray away from the branding (look and feel/components) that the marketer defined.

I think this would require the puckConfig itself to be serializable and passed down from an outside source, rather than through code alone.

[chrisvxd]

A lot of this is already achievable via existing APIs, including the new permissions API.

Most of this stuff is likely pretty user-specific, which is why Puck hasn't provided a UI for it, instead just providing APIs and assuming the user will manage their access control data themselves to match their specific use-case. Having said that, if there are obvious general-purpose scenarios, we can obviously consider new UI.

Component Locking - the drag permission enables you to prevent an item from being dragged. You can add a custom action to the actionBar to enable a user to set this permission. There's an example in the custom UI implementation, which uses the actionBar override, the OOTB drag permission and a custom lockable permission.

Prop Locking - achievable by setting readOnly with resolveData. You could probably implement a field override to add a button to toggle this option. This could arguably be done by Puck.

Component Exposure - achievable by either implementing a components override, or by setting the componentList on the app state.

Prop Exposure - similar to prop locking, you could use a field override to add some kind of locking component and use resolveFields to hide the fields not available to the user.

Default Props - this one is more complicated because you're talking about authoring the config definitions at runtime, which is not a pattern used anywhere else. Puck never writes to config, it only ever reads it. There are probably several ways you could author this config - 1) via an external form outside of Puck (easiest), or 2) via a "promote to default" button a field in Puck, which stores the default props in an external data store and then pulls them in with resolveData, or 3) via a component-item override, with a button that opens a form that authors your config.

Component Count - the new insert permission enables you to control whether a component can be dragged. Granted, there's no easy way to track the number of instances of a component, but you could probably track that yourself with onAction.