Read only for some users

[mmorley0395]

Hi, I'm having trouble setting roles on a per table basis. I've found a few discussions here, that this was an intended change in V3.

I've made a few roles, let's just call them viewer and editor, with viewer inheriting from editor in the manage roles tool (that is, editor on right closer to admin, viewer on left, closer to app users, tethered together.

I've set my tables in the data tab to be accessible by the editor. I've set my screens to be accessible by the viewer. Based on the budibase university video, this should be adequate, but I'm still seeing a permissions issue when trying to view the screens as my viewer.

In general though, it looks like the documentation is a bit out of date on role management, so just wondering if there is still a way to set read/write based on table for various users.

The recommendations I've seen are to create a view and then set read/write there. This doesn't really work for a few reasons: I have 'not null' constraints on a few columns in my DB; budibase requires that those remain writable. Because of this, I can't really set user controls. I can set my least privileged roles to only read certain columns, but I can't control write access on those not-null columns or the display columns. Image below. Greyed out fields can't be toggled between read/write.

All this to say; I would love the ability to set read/write permissions per table per role, this seems like something that already did exist but does no longer?

[ConorWebb96]

Hey @mmorley0395,

We no longer distinguish between read and write permissions at a granular level. Instead, you’ll likely need to use a combination of views and component-level design changes to control access.

• Start by doing as much as possible in your views:
• Configure columns as read-only or editable based on specific roles.

Ensure views have the correct access settings. By default, most views inherit their table’s permissions, which are typically set to App Admin.

• For required fields that shouldn't be editable by certain users:
• Use the design area to adjust component settings.
• Apply conditions to make components read-only for specific user types.

Form blocks also include a view-only toggle, which disables all interactivity. Additionally, you can disable CRUD functionality, causing the form to behave as a read-only table.

If you were referring to the User Roles documentation, thank you! I've updated the page and removed outdated content.

I hope this helps you!

[mmorley0395]

Hey Conor,

This is super helpful, I appreciate your time in writing it out and updating the docs! I think the only other thing I'm curious about with this is that the views do not seem to truly be read-only copies of the data; updating a value in a view propagates to the underlying table in the DB. Is there a way to restrict that functionality, other than making read only views?

[ConorWebb96]

Hey @mmorley0395,

You're right, they're not. Views must always have the required fields set to editable.

Would a simple GET request using the public API be sufficient? If this is used as the data source for a table or data provider component, it would create a purely read-only screen. There would be no risk of updating data unless users are explicitly given access via a PUT request.

That said, if you build your screen using a view or table and none of the components support editing, your users will not be able to modify the data.

I hope this information is helpful.