Hi,
I am trying to configure specific permissions and role for a new user/member which would be like this:
to see and access only some (selected) tables, others will be hidden - I can manage it via table’s context menu Manage members
for some tables that will be accessible I will set the Editor role, for some only Viewer or Commenter - again I can manage it by table context menu
for these two role categories I would like to allow user also using filters and sort features - BUT THIS IS NOT POSSIBLE - it’s possible only for Builder role, but problem is that I don’t want to allow the user to rename/duplicate/delete tables or views.
Would it be possible to change the behaviour or add even more granular control for user’s (members) permissions and allowing/disallowing these specific functions - filters, sort, group?
That’s right, the first two points you mentioned are available, as it’s possible to assign roles to members or teams at three levels: Workspace, Database, and Table.
It would be very useful to allow/deny these user roles with lesser permissions (Viewer, Commenter, Editor) these functions - filter, sort, group, colors hidden fields.
As I was talking about the need to allow filters and sort features to low-role collaborating member, I would also like to restrict him to use hidden fields function - f.e. we have some more sensitive data in the table and I don’t want him to see or change these specific data.
Making it more granular on a level of fields and rows (permissions for users or groups for these) will be indeed very useful and can fulfill some of needs I have described.
But still I believe that there should be also the option to allow or deny “filter, sort, group, colors hidden fields” functions for members with the role lesser than builder.
It can be useful for scenario where I need from user (commenter) to just browse and comment (I would say tag) some rows but I don’t want to allow him edit or delete any data. Browsing a searching is very difficult and time consuming if I can’t use criteria or conditions (which means filters and sort).
OK, I just finished reading the gitlab ticket #2210 and agree with everything that is written there.
Sure, allowing lower level roles to use filters/sort/hidden fields only temporarily (and locally) if using collaborative views, so the changes won’t be saved back into these views and even won’t affect another user working with the same collaborative view, and allow it (also saving) for personal view - that makes sense.
But here still would be very needed locking or restricting to display specific fields or rows (f.e. with sensitive data), even in personal views - simply said, more granular permissions for members or member groups, defined by builder or admin (or creator of the table).
(I am going to put it into the proper gitlab ticket, OK?)
