This is becoming more and more of a problem for me in Coda.
I’ve been working on information that is locked under NDA but I can’t share it with my partners unless I create a separate doc.
Because there’s no way for me to organize my Coda docs, I have a long-running list of related items that I can’t clean up. I may need to revert to Drive until this is available in Coda.
Requests:
This would also be helpful for sharing a doc with someone who is afraid of “messing up” important data accidentally. They could be allowed to see all sections the doc, but only be allowed to edit the sections that they need to.
@419 out of curiosity, what would happen to any views or =formula based on tables inside of folders/sections that the user can’t see? That feels like one of the hardest challenges in a permission system IMO.
Here’s my thought on how it might work.
Caveat 1: You cannot change permissions within a doc
Sharing things piecemeal is really difficult in this scenario, because of the problem above.
Caveat 2: You can export a view
To fix this, my proposal would be that we can export a “view”. Views are mutations of tables that change their source content. To make sure there aren’t data inconsistencies between coda docs, I’d suggest exported views in v1 be read-only. This way the data flow between coda docs is unidirectional.
If you revoke permissions on the parent document, then the view remains fixed in time. Breaking the link is a lot easier to manage and would minimize user confusion.
When the parent document’s table changes, linked views are updated (probably on like a 1min lag time or something).
What it would look like
In this example, I’ve modified the coda interface to show a “published” view. Filters have already been applied, making the view gain a light green outline. (Maybe orange? Does coda like orange?) The details of the publish dialog are somewhat straightforward, explaining that the content visible in the View is what will be available in other coda docs and that this doc will remain the source of truth.
In the receiving document, we would have an option to use another Coda Doc inside of the Import From. Using Google Drive’s file picker, you could select a file you have permission to, which would then list only the tables flagged for export.
Once imported, a view referencing another coda doc would contain a link to the original table (just like any other view), but the permissioning has been handed off to Google’s share model which is pretty robust.
Aside from those three rules, it’d be just like any other table view. Sortable, queryable, used in lookups, and more.
Thoughts?
Thanks for surfacing this topic @419 @zoglow (and for the awesome exploration @jakobheuser!) - this is actually one of our top scenarios we’re working on in our near term roadmap, and definitely one of the most complex based on the challenges articulated above. Drive (and other content systems) do have a robust system of ACLs that we hope to take advantage of, partially for ease of implementation, but also given it’s a model users already understand and can interact with. Sub-doc permissions solve a few of the Coda challenges articulated (I wish I could share notes with customers without sharing our entire CRM doc!), but requires another layer of education and nuance within a single doc.
To that end, the idea of “cross document sharing” is top of mind for us - in particular these questions:
What information makes sense to be portable initially? If sharing Tables / Views, what scenarios does that unlock? If sharing an entire Section, what scenarios does that unlock? In the case @jakobheuser mentioned of Table mutations based on objects outside of the table, you could foreseeably include these reference points in a Section you share. Which scenario is more important to solve first?
What would feel like a natural entry point? Which ways would someone want to interact with data once it’s connected? For example, should this feel like a “data source”, feel more like a linked spreadsheet, etc…?
This feature unlocks a new type of spread- we anticipate there would be more docs, not less. I personally would love a more usable doc list, but I’d need to couple that with some sort of map that shows the interconnected data structures. How would you want to visualize it?
@jakobheuser Thank you for your thorough dive into the potential for permissions! I’m not certain your proposed solutions are what I’m looking for, but they’re interesting to consider nonetheless.
Which scenario is more important to solve first?
For me, having per-section and per-folder permissions would be an excellent start. This prevents you from having to worry about granularity of tables/views/etc. at the onset while still allowing flexibility within a doc.
What would feel like a natural entry point? Which ways would someone want to interact with data once it’s connected? For example, should this feel like a “data source”, feel more like a linked spreadsheet, etc…?
I don’t quite understand what you mean.
This feature unlocks a new type of spread- we anticipate there would be more docs, not less. I personally would love a more usable doc list, but I’d need to couple that with some sort of map that shows the interconnected data structures. How would you want to visualize it?
The Drive file structure hasn’t changed in nearly a decade. As an option, I’d love to see a node-based system that focuses more on relationships than hierarchy.
I have the scenario where I have project management docs that are shared with others as well as a private planning/to-do doc. I’d like to pull in to-do’s from the project management docs that I share and that I’ve been assigned to me. To do that I suppose a many solutions could work, with different advantages/disadvantages:
No easy answers I suppose.
In our case, we are creating a wiki for the company and some tables should not be editable to some team members.
They are afraid of messing up the data.
I am afraid that they could mess up the data too : )
This is very interesting. The complexity that comes with it all is fascinating.
Right now I have 1 doc that I use for internal client and 1 doc I use for client shared. I guess if you could share tables/sections/folders from 1 coda doc to another, that would be incredibly incredible and solve tons of the issues we are currently having. (doing a lot of copy/paste between Coda’s and data getting out of sync).
The thing with that though is it’s often sharing a table. If I share a table view (that has hidden columns) to another coda doc (client doc), they should not be able to “show” the hidden columns. I don’t mind keeping a “filtered table view” right below the master table that we can then share with a client doc and have it synced.
Permissions would be great too where we could just use 1 document for internal and client management. That way we don’t need to deal with having 2 docs. I wouldn’t mind if data was restricted by folder by example. If a folder has permissions then the sections within the folder share those permissions and the views and passing of data between tables would just be internal there. At least as a starting place… I could potentially merge our internal client doc + client shared doc into 1 doc that way. Yes, we’d have some organization restrictions, but it’s better than doing tons of copy/paste between Coda Docs.
It’s already such a pain to jump between Coda Docs that it makes jumping between client shared and internal client such a pain. This would help with that.
Really excited to see what the team comes up with and does!
Also being able to just edit the data rather than the schema would be amazing - when people have not had too much experience with coda, it is super easy to mess stuff up accidentally… As the user base grows and people are told to use this tool rather then chose it themselfes, this will be an increasing issue…
Question is, does it still make sense to go forward with the mindset of more docs? I’ve seen multiple people here mentioning they use just 1 doc per project, which is exactly what I’m doing. The in-doc navigation is so awesome and intuitive, everything has context just a click away and everything can be connected.
Anyway, the use case I just came here with is, that I created a table with some feature prioritization, where unlike everywhere else, I don’t want my colleagues to vote, but rather just look at the table. Understandably, the first thing anyone does is changing the priority, as if they were voting. Locking the table would be awesome here, as well as adjusting section permissions.
I think granular permissions could be a fantastic addition, so here are my two cents:
I did not anticipate a doc spread initially since I envisioned granular permissions at the document level. I like the idea of cross-document data sharing, but saw it as a related but separate issue. That said, a table that comes from another document could have an icon over it when looking at the connection map. This icon could indicate if the data is one way (cannot edit in this document) or two way (edits apply to the master). If you have permission, you can click on the icon to see what document the table comes from and open it up.
Additional Comments
One of the permission levels that either does not exist or is not easy to do in competing products is the ability to give permission to sort the data without actually changing the data. For example, if I have a table with one or more Select Controls at the top that filter the data in that table, allowing a user to pick an option from a Select Control without being able to otherwise manipulate the Select Control or change the data would be great.
The article on User Views was great (Creating user-specific views | Coda Help Center). I have already mimicked this in my document to create a personal section for each person. That said, being able to more easily go further with shared data would be great. For example, I made a “personal” section for each user by having a section that show stats related to each user using the User() function. So, everyone clicking on that personal section sees something different. With Sections containing shared tables/data, however, it would be great if users could more easily filter views without impacting each other’s view of the data.
@evan this feature would be great for us and i’m looking forward hearing more about your plans.
We work in the residential care industry. We therefore have a facilities and admin back office, combined with a care provision sides to the business. Both sides regularly need restricted access to the same information. Here are some use case examples that help to summarise how we foresee using Coda in the future.
What information makes sense to be portable initially? If sharing Tables / Views, what scenarios does that unlock? If sharing an entire Section, what scenarios does that unlock? In the case @jakobheuser mentioned of Table mutations based on objects outside of the table, you could foreseeably include these reference points in a Section you share. Which scenario is more important to solve first?
I could see View sharing being a good place to start. A read only View would be sufficient in some instances, but a locked View, with editable fields, would be very useful. Only the columns shared in this view would be editable without the ability to view/change anything else.
What would feel like a natural entry point? Which ways would someone want to interact with data once it’s connected? For example, should this feel like a “data source”, feel more like a linked spreadsheet, etc…?
I think this depends on the particular use case. We would definitely use both read-only data source sharing and fully editable spreadsheet sharing.
This feature unlocks a new type of spread- we anticipate there would be more docs, not less. I personally would love a more usable doc list, but I’d need to couple that with some sort of map that shows the interconnected data structures. How would you want to visualize it?
I have a multi-dimensional schema drawn up. Yes, the number of documents is potentially higher, but only in-line with the different levels of access we need to create. We foresee permissions combined with cross document/section/etc sharing as a way to reduce the total number of tables and sections. The alternative would be multiple copies of data siloed within each access/permissions level.
Really hope this helps!
Buttons will be fantastic for this.
Give ability to share individual sections/folders, but only buttons can be used for interaction for those with such access.
My personal use case is aggregating data from several documents. I manage a school, and I would like teachers and students to have access to some of the same data (courses, dates, assigned tasks), but not all of the data.
Currently, we only use Coda for teachers, and manage the student’s tasks on Trello, where we copy-paste exercises stored on Coda; it’s not ideal, and being able to lookup data from another document would be grand.
I understand the complexity challenge. I propose “simply” (sic) that, as an owner of both documents, I can access any data in any. However, another used wouldn’t be able to create a formula looking up a doc they don’t own; They could only see the results of the lookup that I wrote.
In-document granular permissions would also solve this, albeit (for me) less elegantly.
Just curious as to whether there are any news on this feature request.
For us it is a must have. We have a master Coda doc to track all our projects, from budgets, expenses, and time.
Since all projects have different stages and we must track time spent on projects, we cannot create a separate Coda doc just for logging an employee’s time.
I would like to share only the “My Summary” section, where each user logs his/her hours.
I attached a screen capture to illustrate our use case.
Thanks!
Mariano
Love “Adminland” BTW 
Our team is looking to migrate from all those pesky Google sheets to Coda. I’m the one in charge of the migration, among other things.
I was looking over the specifications of your application and I found that section level access control is not implemented yet. This would be one of the features which we need the most.
To explain a bit, our team is formed by core members, which should have access on every section possible, and a large number of freelancers; each with its own goal and scope.
With section level access control, I could create separate section for each mini-group of freelancers and give them Editing rights only inside those sections. Otherwise, I don’t want them to have even view access to other sections of the Coda app. Our freelancing mini-groups have specific purposes and we could do that with Google Docs, by simply creating a separate Excel for each group.
The downside of that is the number of sheets we’ve reached, which is driving us crazy, and the fact that you sometimes get lost while navigating.
That would be my idea of section level access control.
This is the only thing missing
While it’s much simpler than the granular permissions discussion, one very handy option would be the ability to password protect a link that “anyone can view.”
It offers no centralized authentication, of course, but there are quite a few situations where I need to share a document to technologically unsophisticated people who are never going to create an account or understand the app, but who can enter a password.
I did try searching topics briefly before posting here and couldn’t find one dedicated to this, so I thought I’d toss it in here. Airtable’s implementation, if an example is needed, is easy to understand and works cleanly.
Thank you!
+999
This is definitely a must have! Also to start with a simple solution without any complicated sophistication, meaning:
Sharing a folder/section in a view mode with the possibility to only interact with predefined actions ( button/controls) would solve the majority of problems here! Someone already mentioned that!
