Questions regarding Hide/Lock features


I’m one of the people in charge of Configuration Management in my organization (a small team of around 18 people, including developers, managers and HR). Naturally, I’m very interested in exploring ways in which Coda could replace some of the tools we use every day. I’m optimistic of the benefits it can bring in terms of UX, simplicity and lower costs across many use cases.

I’ve been using Coda since march and have successfully introduced the use of Coda (Free Plan for now) in some key workflows that involve relatively small docs. We’re considering the possibility of investing in Coda’s Team Plan, but first I’d like to check if it’s feasible to do what we have in mind.

I have carefully read the plan descriptions in the Pricing page, and the info you can see when clicking “Locking” and “Hide” over a section in a document, but I’m still a bit confused regarding how these features work in practice. So, if it’s ok with you, I’d like to explain a basic use case, and I appreciate if people using the Team Plan (or above) can help me clarify a few questions I’ll write below. Thank you very much in advance!

USE CASE: Time tracking

I’m thinking about using a Coda doc as a basic time tracking tool. To simplify things, let’s say I have a table with four columns: Person, Start Time, End Time, Task description.

One way to put it in production would be to share this document with all the team, and trust that people add/edit their own time entries on the one master table. However, it would be nice if this had a little more control. Specifically, that each person could only see/edit time entries relating to his or herself. It’s not critical to completely prevent people from seeing other people’s entries, but if it can be done, even better.

My questions about this:

  • If I (as the doc admin) use “Hide” on a section, does it prevent other people from “unhiding” it? Is this related to any setting seen in the “Locking” menu?

  • Let’s say I have my one master table, and then create one view of this table for each person in the company. Each of these views would be filtered by the Person column. Can the locking permissions be set up such that people can add/edit rows on their corresponding views, but not be able to alter the value under the “Person” column (messing with other people’s entries)?

  • Under the Locking settings, I see that the option “Interact only” includes “Add rows” and “Change table values” but I don’t see “Delete rows”. Does this mean that under this locking strategy, people (non-admins) can never remove rows from those tables?

These are my main concerns for now. Any info or suggestions are very much appreciated. Thank you!

Hi Leonardo, welcome to the Coda Community,

The following comments I’ve made here assume you will only set admins to have the ability to unlock a section, if all editors have the ability, they can edit anything they want.

The “Hide” feature is not a “permission to view” feature, it should be treated simply as a clutter removal feature. It is not related to any setting in the “Locking” menu.

This can’t really be done with “Locking
While a user that has “Interact-Only” would not be able to manipulate the layout of a table, preventing them, let’s say, from unhiding the column [‘Person’], they can still access the column from expanding the row and editing it there. (I think that Coda should close this loophole, but other use cases may want it to remain)
I would instead make [‘Person’] a list of emails, then filter the table by [‘Person’] = User().Email().
Once “Interact-Only” has been set, the user cannot alter the filter, therefore it will not allow them to see anyone elses view of the table. This does not prevent them from seeing the original unfiltered table, it just isolates the view table

From what I can tell, if you set “Change Table Values” to ON then anyone can delete a row.

1 Like

I would instead make [‘Person’] a list of emails, then filter the table by [‘Person’] = User().Email().
Once “Interact-Only” has been set, the user cannot alter the filter, therefore it will not allow them to see anyone elses view of the table.

That is brilliant. I hadn’t thought of that, and it would mean having just one view instead of n views (where n is the number of people).

I’ll try a proof of concept and show it to the rest of the CM team, see what kind of feedback it gets. Thanks for this and for all the other answers!