Granular Permissions

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

@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.

5 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.

2 Likes

Here’s how y’all can implement access control in your docs!

(please don’t. I did it just for lulz)

1 Like

I’m trying Coda and setting up a complete company structure, and this seems to be a problem.
We can invite specific members to folders at the workspace level - and keep others private. This is great for most cases.

Where it is breaking down is that we have many projects, and members should only be able to view the projects that they are part of.

Here is the initial prototype structure, with the intention being that all projects go into the Projects folder, each as an individual document:

However it appears there is no way to limit access to the documents within the workspace folder to individuals. Does anyone know a workaround, or perhaps a suggestion on a better layout?

If not - Coda devs is this on the roadmap? Thanks!

Replying to myself, so one solution is to put all the projects in another workspace, and then put each project into its own folder and set invitations as needed. I tried cross-workspace table syncing and it works. Not sure if there are other limitations yet.

This is a hack though and problematic:

  1. Doubles our plan price - we are starting small with coda and are a small company.
  2. Instead of just having a project in a doc, now we need to put it in a folder also.
  3. What if we find other doc-level permission issues in any other of the above folders in our workspace, we can’t just keep creating workspaces and adding paid plans just for permission access…

Would love to hear from Coda devs - is the intended solution? Forcing us to buy two plans just to be able to set permissions in a reasonable way, artificially segmenting our workspace (now we have to send two invites to users, etc), seems far from ideal.

I’ll try contacting support because we need to know what the plan is here so at least long term we can look forward to a solution. We could work around this for now by giving each project its own folder in the main workspace, e.g. “Project A”, “Project B” folders, but that will get messy fast.

Other than that though, after 1 day playing with Coda, I have to say it is so exciting, great job!

1 Like

You can make the Projects folder private, invite only those who should see all docs in the folder, and then individually share each doc with specific people.

They won’t see the Projects folder in your workspace even if they are members of your workspace but aren’t added to that private folder. Docs shared that way will display for them as not from any workspace. They’ll be on the list of All docs and of Shared with me.

1 Like

Hi Paul,

That sounds like a perfectly workable solution…wonderful. Thank you! I didn’t pay for a plan yet so was not able to try it.

I am in the process of filling out the various risky sections in the folder structure I shared to see if there are any other blockers. I found a couple bugs so far that I will be reporting, but otherwise things are going well - burndown charts, data sources and views, formulas all good stuff. And I expect things like cross-doc sharing to get better (bidirectional) over time, for now making do with the limitations.

It’s so nice to be able to define the flow just as we need it, and not have to worry about exporting data or using an API to represent things in ways that aren’t possible with preset tools like Asana, or even Jira.

These are great notes on what the wants are for permissions and also great use-case examples. There are quite a few questions about how to handle the smaller details of permissions like these and some solutions take more work than others. These examples give us a good direction to work with though.

Thank you all for the feedback!

1 Like

FYI @Ed_Liveikis you can have bidirectional cross-doc already. Not ready for prime time yet and not widely announced, but not hidden either and kinda works (see gotchas):

1 Like

Great @Paul_Danyliuk - yes I’d like to do the master, single-schema data sources common project management data structures that can store all goals, tasks etc for all projects, and the have filtered views within projects with permissions ensuring that only the project-specific data is available to permissioned users.

One major goal this would help solve is a master “My tasks” list that can pull data from any project. This is also something that is not possible Notion at all - so a competitive advantage opportunity for Coda.

I’ll probably wait until this is ready for prime time, at least for now since I’m also knee-deep in learning all the other basics, and I have the option to “push” project-specific data up to a aggregated (modifyOrUpdate) table via buttons, as illustrated in the post:

1 Like