#Dealing with cascading access control on container fields

9 messages · Page 1 of 1 (latest)

mortal dagger
#

I want to create an "update opt-in" collection that is in general read-only but some specific fields can be updated.

As far as I understand access control is cascading downwards from parents to their nested fields. If I disable update for an entire collection, all it's fields will be disabled no matter what their individual update function does.

The same applies for any container fields like arrays, blocks fields etc: Disabling update on the array does restrict all editing directly affecting the array, like creating and moving rows. But it also locks any editing within the array rows.

That's unfortunate for me because I would like to create a block for example that contains an array field. This should be set up by an "admin". If an "editor" edits this later, they should not be able to change the blocks order, add new blocks or array rows. They should only edit the "leaf" fields inside those containers.

Is this not supported by default? Only option I see so far is leaving the actual access control open but enforcing these rules with field level hooks. But this has significantly worse UX that I would have to counteract with custom UI components.

Am I missing something?

woeful willowBOT
mortal dagger
#

Maybe @spiral trail any insights? I think this is not really a niche case. For example what if I want a "translator" role. This role should only be able to edit localized fields but not the structural fields around them. So they can't add/move blocks or array rows but they have to be able to translate texts or swap images.

spiral trail
#

Hey! I was looking at this last week but I was traveling so I didn't have time to respond

#

The cascade is intentional: if a parent array or blocks field has update access disabled, that readOnly state flows down to all children, and right now there is no way to override it

#

that said, you have a couple options:

beforeChange hook — leave access open on the container, but validate the incoming data server-side. Compare the incoming row IDs/order against the saved document and throw if rows were added, removed, or reordered. Editors can still attempt structural changes in the UI, but they'll get a validation error on save

custom component — override the array or blocks field component to hide the add/remove/reorder controls for the relevant role. You keep full update access on the container so leaf fields stay editable, but the structural controls simply don't render

mortal dagger
#

hey @spiral trail thank you so much for confirming, I had these two otions already in mind, glad to hear thats the right track 👍

woeful willowBOT
spiral trail
#

No problem!!