@Ayuba_Audu – Thank you so much to you and your team for the incredible progress on content sharing in Coda. It’s been amazing to see the introduction of two-way cross-docs and the upcoming sync pages without requiring main doc access!
As I think about the many scenarios where I can’t wait to replace cross-docs with sync pages, one recurring need stands out: locking columns. Often, we have data that should be visible but not editable, and other data that could be more robust if a broader audience could edit and maintain it.
Would love this feature for so many reasons. I love smart suites implementation where you can set roles and then certain roles can edit/view columns or even not SEE certain columns.
Only workaround right now is setting a new column as formula that references the editable column
Many thanks for the feedback and kind regards, @Astha_Parmar!
While it’s not something we’re specifically tackling as part of sync pages, we’ve explored various approaches for both column and row security across various hackathons.
Similar to locking, we see needs for this independent sync pages, so you’re not alone as we’ve heard similar feedback from customers and in our research. I do agree the combination of both building blocks as you’re suggesting can be powerful.
I’d be curious if you have examples of both scenarios you mentioned i.e., visible, not editable versus editable? Additionally, are there scenarios that come to mind where it’s important that the column isn’t visible (can’t unhide or see to unhide) or editable?
PS: in case you missed it, we shared an update today on Sync page access control (step 3).
I would wager to say that all we really need is to make the “Disable if” feature available for all column types, not just buttons. This takes a tried and tested existing feature and expands it so that we can leverage the amazing CFL achieve any scenario where we want to make a certain cell editable or not based on various business conditions.
If you want to go all the way with this awesomeness, then we can also have a “Hide if” feature available on all columns. However, this one will be tricky, because you will want the “hiding” to apply at the view level, not at the root table level - a bit how conditional formatting currently works.
Such formulaic disabling and hiding will not be a security feature, just as page locking isn’t. It’s just a tool for the maker to offer better UI/UX to the doc’s end users.
This is my first post in the community in almost a year. I had given up on the product due to the lack of progress in this area as well as on on shareable editable sync pages. You are the PM who is working hard to deliver the latter, maybe you can also be the one who delivers the former
@Ayuba_Audu – a big, huge yaay on the sync page sharing shipping I am super excited about this!
Here is a concrete scenario that I imagine applies for a ton of business data/functions:
Visible not editable
I have designed a series of HR/Talent data docs for an org.
The base data for almost all the applications is the Employee Database which we pull from their HRIS system via an app-script, which is updated overnight.
This employee data (Names, email, location, etc.) is visible across several contexts. In each of these contexts, this data should be visible but not editable.
Combo of Editable and Non Editable OKR Doc
The employee name and email should be visible but not editable.
But, teams the person is currently assigned to are best editable in this context.
Career Architecture
Current employee data (salary, title) being pulled from the HRIS should not be editable.
But proposed level, title, and compensation should be.
I imagine there are a ton of business contexts like this where there are columns that should not be editable if the permissions are set to make changes to table values, and others that need to be edited.
The main goal here is to set the end user up for success…so they do not accidentally edit/delete something they shouldn’t, but open up data they own and should be able to edit.
Theoretically this could be achieved by creating mirror formula columns…but this runs into a very real scalability challenge – complexity that both the doc maker and users cannot sustain.
I would settle for something super simple: a setting on a column that enables ‘Locking override – stays locked in interact mode’. Unlock page to edit.’
I know these likely aren’t complete or viable solutions, and trust the coda team has a way better handle on what would fit the wide range of needs. Just sharing as an example of what I wish I could do
Many thanks for the detailed examples and context, @Astha_Parmar and @Nad!
No worries about how complete or viable, as it’s much more important to understand the use cases and early thoughts of how you might expect it to work.
I am super excited about this!