Thanks all for the feedback!
This feature targets a couple of common scenarios where it’s helpful to hide some sections or folders from everyone. For example, customers often show us docs with “You should not be here!” disclaimers on sections that store supporting base tables that no one needs to see or change. Now those can be fully out of the way.
One tip if you need frequent access to a hidden section: add it to your shortcuts, and it’ll be accessible all the time.
We do hear you that building on this feature to enable more scenarios would be great. There’s a few reasons we started here. For one, this is an incremental feature we could get out quickly that addresses a set of real needs. It’s also a familiar pattern for customers coming from spreadsheets.
To go beyond hiding as an organizational feature, and securely restrict which content individual users can see, requires a good deal of additional work to implement. Given how inter-connected Coda docs are, loading only certain sections while preventing access to the content of other sections is technically complex. The content in one section often depends on tables or formulas in another section, and de-tangling exactly what needs to be loaded is complex. We have ideas on how to do this, but it’s a large undertaking.
This is partly why we chose to ship Cross-doc first, as it lets you specify clear boundaries for what data should be shared in cases where separation of data is important.
We also want to incrementally improve the product, and allow features to build on each other. Cross-doc and Locking are still relatively new. We want to learn how you use each of these features, and Hidden sections, and what new patterns they enable together. We also know that some scenarios will still need more, and look forward to better understanding these with your help. Feel free to share more examples below.
We have explored ideas similar to those some of you have suggested, and carefully made decisions with each of these first features so that it’s possible to iterate and expand them over time. It’s great to hear the interest and excitement for more.
I also want to clarify that the upcoming permissions feature, while it allows you to restrict who can unlock a doc, is also not intended to be a security feature as it’s not enforced on Coda servers. Rather, it’s strictly a usability improvement enforced by the Coda client. This can prevent certain users from unlocking when they open a doc in their browser, but anyone who is shared a doc with Edit access can still change any parts of the doc through other mechanisms such as our API.
The approach helps keep Coda a flexible surface for a wide range of scenarios. We see many docs where customers want to enable changes through one part of a doc, while restricting the same or similar changes elsewhere in the doc. For example: allow people to change values only in one filtered view, but not in other views of the same table. Or, allow people to press a button in one section that adds a row, but prevent them from directly adding rows in other views of the same table.
While this means that enforcement only happens in the Coda client, this approach gives the most control to specify exactly what actions you do and don’t want enabled throughout a doc, in a way that matches the needs customers have shown us in their docs.