Granular Permissions

I exactly have the same usecase with time log.
I know this is somthing I already asked, and many others users too, and I am sure the team is working on this.
I hope this is going to be released soon because this is one of the few feature that will make Coda so relevant in so many usecase you can’t really use it for right now…

1 Like

This is essential when developing any significant application. Too much time is invested in coding it up just to have it be easily deleted or damaged, etc.

3 Likes

Coda team,
Any update on this? It’s obviously a popular request and it would be great to get an update on timing, if possible.

11 Likes

Without a permission system many companies (such as mine) simply can’t adopt Coda. There are many users who would simply be overwhelmed by Coda’s functionality and could accidentally delete something. Also, certain parts of pages might be classified.

Additionally, a “Database Lock” switch as in Notion would be very useful, even when I’m the admin I don’t want to accidentally mess up things (add/remove columns, etc).

5 Likes

I am definitely on board with this whole discussion of implementing a restricted access/permission system. I realize this is a complicated component and will take some time to develop. In the short-term, however, it would be nice in your embed option that is setup with view-only access that you can have an option to make it so any columns that are hidden cannot be unhidden. When you expand the row, it gives the option of showing hidden columns. I currently have all personal information hidden and don’t want those with view only rights to be able to see that.

4 Likes

Hi all, we appreciate all of the discussion and feedback around these requests! We’d love to collect more detailed information on the specific needs each of you have to help inform our direction.

Could you take a few minutes to respond to this survey?

Thanks!
Nathan

2 Likes

Now that the survey is closed, let me chime in here:
What I would need is an “Add-only” or rather “Create and edit own rows” access – i.e. anyone with the link should be able to add new rows to a table, but neither edit, nor delete the rows added by others. The row objects already “know” whom it was .CreatedBy() and .ModifiedBy(), so I suppose this should not be very complicated.

This might be the same access level as @Francesco_Pistillo suggested:

only interact with predefined actions (buttons/controls)

1 Like

I have discovered the way to sync data from one doc to multiple user-facing docs (e.g. from some admin panel to individual user dashboards) using Zapier (a simple 2-step zap per table that needs to be synced) and some hacks. This may solve some of your needs to restrict access to the “source of truth” doc and only show those data to the users that they should see.

It’s not a trivial write-up, so I guess I’ll record it as a screencast somewhere in the coming few days. Stay tuned.

(also a shameless plug — you can hire me to build such doc for you :wink: I’m fully booked at the moment, but will be available from ~Aug 1st)

4 Likes

And here’s finally the screencast:

2 Likes

The case in-point would be good for validation and testing. This is exactly what I was looking for. But also concerned that this may not solve Granular permissions at an internal organisational level, i.e., I have my team on one doc and would like granular permissions among my team, which might be a standard necessity for Admin panels and ERPs.

I have wondered about a way to lock your filter on a table (tagged to a specific User Role, say Admin) for the same. Would love to hear thoughts from the community.

One thing that makes the permissions necessary: It’s very easy to accidentally add blank rows or change data by clicking to deselect the table or a given cell (maybe it’s habit but I like to deselect everything once I finish making a change. I know I can be careful enough to keep from changing data or even (gasp) formatting, but I doubt that the people I plan to share my doc with will be so prudent. I need the ability for them to be able to enter data (in select locations, like the “form” layouts), but not change formulas, or change the table structure in any way!

Another thing I’d like to do is have Admin users and Parent users (we are using this for Cub Scouting). Parents need access to their children’s data, but should be prevented from seeing other children’s data. Admins (our leadership) need access to all data to provide insight to those parents who won’t be accessing the doc, and to make decisions about our program. I need a method to keep data segmented to the appropriate users and forbid others from seeing it.

2 Likes

I’m looking at using a table for a quick bug report from some external testers, and here the granular permissions would be a great help as well: I would protect the test plan bullet point descriptions, and let the testers enter the checkmarks and comments against each bullet point

1 Like

This is much needed!

1 Like

I was thinking of a work-around for the same but from a different approach, considering that segregating views to the doc User() is the main problem.

If there would be a way to embed tables specifically anywhere, you can re-use Coda’s embedding tools to make another doc which would keep both connected therefore. At the same time this could solve a bigger problem, i.e. being able to embed a specific table in any website with embedding capabilities.

What do you guys think of this? Would love to know. If required will make a different topic.

  • Good idea, solves the problem
  • Good idea, but doesn’t solve the problem
  • It could work
  • Bad idea

0 voters

@nathan, Not sure what stage you guys are with this feature, and I had filled the form before but only now came across this issue: Access to version history.

Everyone you share the doc with has access to the full version history. Even with ‘View-only’ access.

What happens on this forum sometimes is that people ‘clean’ a doc of sensitive data before sharing. That’s basically useless.

I’d say only the highest permission level should allow that. Then probably an ‘Editor’ level could grant access to the history but only back to the point when the person was made editor.

3 Likes

Could the functionality that @419 is asking for (section and folder level permissions) be achieved by creating a “rule system” that checks for users access level i.e. admin, editor, viewer. This would allow the general function of the doc and it’s data to remain the same while enabling a few possibilities:

  1. Allows admin to designate per user access to Sections or Folders. This should in theory disable data changes in the accessible areas of the doc that would alter anything behind the permission wall. This would be similar to user permission on macOS. if a file is set to read/write for the “Admin” group and read-only for the “everyone” group then “admin” can alter anything at will however “everyone” will not be able to alter the file. move it’s location, change structure etc.

  2. Prevents data modifications outside of commenting and allowed elements (this would require admin/editor ability to lock elements in the doc). In theory this would work similar to locking elements in Apple Pages and Microsoft Office allowing any element that is not locked to be modified under the “editor” group permissions.

  3. Allow for something similar to @Dalmo_Mendonca suggestion to limit a viewers history access to anything prior to their initial access date.

I feel that if possible this would be an elegant and user friendly solution to this issue. Element locking can be an option nested in the context menus and permissions can live within the doc settings and possibly the share menu as well. I’d love to hear and thoughts on these ideas.