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.
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:
This is not on the immediate roadmap. Just to reiterate, these features are not necessarily security features. A user can copy a doc or craft a formula to access data in a doc. If you have sensitive information that cannot be shared with others, I would encourage the use of cross-doc where you keep that private information in a separate doc all together and only carry over the information you want to share.
Hi, you’re definitely losing some Business Cases here, I was just looking for better granularity and to just don’t allow the document to be copied, as per: This Other Question
Because even within the same company, you want some parts of the process to be editable/viewable by some and some parts don’t, even if data is in the same master table. Was my use case here (for the company I work with, with plenty of process and possible makers)
There is maybe a workaround for the access per column, dividing a master table in more tables per group of access rights for this (IDK) but this heighten up the bar for makers (more learning required) and don’t solve the copy issue, still, this is a very nice platform, looking for more ways to use it!
I am so sorry… If not this feature, then which one? As mentioned above many times, one of the most missing feature is giving granular access… This is also the main philosofy of many applications. Build once use many…
Just following up here. @Paul_Danyliuk and others have helped to guide me in the direction of thinking of Coda documents as…individual documents, not more. With this mindset, the permissions are comparable to sharing other types of documents, like a Google Sheet, which also don’t offer lower level granularity (e.g. Google sheets do not allow individual Tabs to have individual sharing or permissions).
However in Google Drive, you can have complex folder hierarchies to store documents and control permissions.
I believe this is on the Roadmap, but having subfolders in the main Workspace view, for docs to go into would really help with permissions without requiring changes to the permissions within a doc.
Hi everyone! We have what is hopefully some nice progress in this area. Starting today, you can copy a page to a new doc, and adjust the sharing settings of that doc so that your new audience only has access to the new page in the new doc.
Although I am happy with this new copy option, I don’t think is solves what is asked for (and needed by so many people): the new functions makes it possible to make a new doc in a hurry, but since it is completely independent from the original doc, we now have to maintain one more doc.
Since the power of Coda is that pages can have dynamic content based on other pages, the new doc needs (in many cases) to be connected with cross doc, which is not that great of an option in many situations.
I am sorry to have to conclude that this is not really a step forward towards what is being asked for in this thread.