Again running into issues with not having more granular control of User Permissions. Wondering if this is on the Roadmap and if so (Though I know you can’t say when) is it one of the higher priority items?
I think the simplest way permissions could be implemented is on a per-table & per-view basis:
No Access
View
Editor
Creator
If using the same permissions that exist today for Bases then we’d be able to add lot more data to our bases and collaborate with more people because we wouldn’t have to worry about privacy issues.
Great to hear you’re exploring this! Here’s my use case, FWIW.
Industry: Education Base: Student Enrollment / Information Main Pain Point: I need a variety of staff to have edit access, but the fact that they could delete entire records or accidentally goof up formulas that are critical to integrations or reporting makes me really nervous. Possible Fix: Make “record deletion ability” specific to each user? Also, view-specificity for permissions would be awesome! Our housing staff should be able to see ‘Applications’ but never edit them. Likewise, nobody except the all-knowing-admin should ever be able to delete students from the database.
Industry: Delivery
Base: Orders
Pain Point: Call center employees should be able to click a checkbox to mark an order as accepted or completed, but not be able to delete or modify the rest of the columns of a row.
Solution: Permissions for each column of a table or view.
hello Howie, sure, there’s no “one-size-fits-all” solution. Your challenge as a software maker is to come up with solutions that solve the ‘more common’ user needs while keeping the app robust. Comprehensive user permission is an important part making any web based collaborative software powerful. Thank you.
Also keen to see this. I would like to be able to restrict a user to editing and viewing only the rows that they have entered. This would be particularly useful in conjunction with the existing “link to another record” functionality, where I would only want a collaborator to see their own rows in the linked record.
RowShare implements this perfectly by allowing independent control over viewing and editing for any user on any table. On every table and for every collaborator you have the options: View: Nothing / Their own rows / All rows Add and Edit: Nothing / Their own rows / All rows
These rules then apply wherever a user is looking at a table directly or through a linked record field.
+1… the minimum for me would be to be able to restrict access to specific tables for specific users. Anything more robust than that would be totally welcome, but really being able to easily “hide” sensitive tables is what we REALLY need at the mo.
Edited to add: I would like to add that IMO there really needs to be a user type, maybe “Edit Only-Limited”, that only has “add, delete, and modify records” permissions, thus they can’t edit/create/delete views, change permissions, or invite collabs.
I think by simply adding a fourth User Type you could solve a lot of the permissions issues people are experiencing. It wouldn’t be perfect but it would be a super easy (I assume) way to deal with this permissions thing.
Hi @Howie Really enjoying Airtable - pretty new to it but I have already discovered it is a great product. Yes, more refined user permissions would certainly help us. We are a membership organisation/trade association involved with the wine industry and we hold a comprehensive wine inventory; the wines from which are used at our member events - receptions, lunches, dinners, banquets etc. We don’t trade wine as such but just buy, store and drink it :slightly_smiling_face:
I would like to be able to control user access to certain sheets only and for that access to have view or edit options for each separate sheet. So, somewhere in sharing options some way to select permissions such as:-
Per User:
Control access as follows:
Whole base - view only, edit or restrict to certain sheets
If ‘restrict to certain sheets’ thereafter on a per sheet basis
List of sheets and some method to select, on an individual sheet basis - no access, view only or edit
I guess the ultimate would then be to control permissions on each column within a specific sheet.
This would certainly help me give controlled access to certain members of staff who are involved in stock movement. On a very basic level I could then give our store-man access to one very basic sheet to record an order when it is delivered by simply changing order status from ‘On Order’ to ‘Delivered’ and entering the number of delivered items which would then show as available stock in the base. In essence, that would be all he needed in terms of interaction with the base.
I have tried this by embedding a sheet into a web site page but it doesn’t allow me to give editing permissions to the sheet which is embedded - that would be a simple solution if it was possible to edit via an embedded sheet.
Hope all this helps you guys progress this permissions issue. Many thanks
Thanks for looking into developing permissions industry: Healthcare Education organizing Questions and tags for import to EXAMSOFT Base Table List of Topics/ Course of question linked to table of questions and answers and "tags" permissions application Want faculty to be able to access and add question only in table of the subject they teach including selecting the tag that works the best BUT should not be able edit the table of tags.
I need to be able to restrict groups of users from seeing certain fields, tables and views.
I also wish that groups of users could be restricted from making changes to views (column order, grouping, hiding, etc.)
At the moment, I can’t hide sensitive data and people keep changing my views!
Another solution to this issue would be the ability to share tables to other bases. Then we could filter only the information we need to share between different groups of users.
Thanks!
-Donald
Change requests to address the issues being experienced by most users in this thread.
Allow users with “Creator” permissions to:
Determine which Views are visible to each user with Edit Only and Read Only permissions. This will allow us to invite more users into the database but share only relevant and need-to-know data with some users.
Determine what specific actions each Edit Only user can take within the Views they have access to – allow turning on/off the ability to a) edit Records, b) add Records, and c) delete records. This will protect against accidental or intentional damage to the database.
Determine which fields can be edited by Edit Only users within each View. This will Edit Only users to change or update only selected data.
Determine whether users with Edit Only and View Only permissions are allowed to invite new users into the database. This will allow us to prevent lower level users from inviting in people that shouldn’t have access to the database.
