Different view of same table with different access type

[Neeraj_Malik]

Hi
I want to create two views using the same table. On one view I would like to provide add & update option but on another view using same table, I would like to provide just the read-only rights.

Basically what I want to achieve is to create a view on which admin role will have the add & update option but the user role would be having just the view option. So I’ just copying the same view and want to disable the add & update

[JuneCorpuz · Accepted solution]

Hello Neeraj, just go to UX -> Actions find the Add & Edit button and change the condition to

[Suvrutt_Gurjar]

Some additional references-

help.appsheet.com

USERROLE()

Get assigned role of approved user

Additionally, you may wish to take at the following options too.

For table level add/edit permissions control based on user emails/ user roles-

help.appsheet.com

Controlling Add, Update, and Delete

How to determine how much your app users can modify data.

One can create slices (read-only and updates possible) and base views on those slices. Those views in turn could be enabled based on user emails and/or user roles

help.appsheet.com

Views: The Essentials

Everything you need to know to start creating UX views.

[Neeraj_Malik]

Ok, thanks @Suvrutt_Gurjar

[Neeraj_Malik]

This one was quick & handy that I’s not aware of. Thanks @June_Corpuz
Not just it resolved my concern but also gives direction on quite a few things on access based control

[Neeraj_Malik]

Somehow this role-based function is not available for QuickEdit option. No option to change the behaviour of QuickEdit to make it role-based. Is it b’s it’s still in beta?

[JuneCorpuz]

I’ve tested it myself and I can confirm that is it not working in Quick Edit.

I would suggest that you should add the USERROLE formula in Editable If on the columns where you have enabled the Quick Edit.

[Steve]

You could create a read-only slice on the table, attach a view to the slice, then present that slice view to non-admin users. This is a lot easier to manage than configuring access controls per column and per action.

Alternatively, if the non-admin user will never have cause to make changes to the table, you could limit non-admin access at the table itself. This is far and away the easiest approach, and the most secure, but does potentially limit the functionality of your app for non-admin users.

[Neeraj_Malik]

@Steve, Yep I’ve implemented your 2nd option only where non-admin used don’t have add/update. This is more easy & suitable for my service flows.

Thanks!