Maybe we can get Codans’ attention by voting up this suggestion (the voting button is at the top-left of the page).
I am running a business with 20 employees entirely on Coda. The only two external apps we use are for banking/accounting and orders/warehouse management, because they are mission-critical apps and we understand that doc locking is not a substitute for a fully secure permission system.
But here’s the thing, most small businesses don’t need airtight security for pretty much everything else. We are usually just trying to minimize the mistakes of otherwise good-intentioned colleagues, by nudging them to not delete the wrong thing or overwrite the wrong value. We are grown ups and understand that at the end of the day, Coda is a just a (really amazing) doc.
So I beg to differ with @Federico_Stefanato suggestion above: permissions at object level will increase complexity of creating docs and introduce concepts that are not intuitive for non-coders. I think server-enforced permissions were not part of the original design specs of Coda, and they are probably very difficult to add now without breaking existing docs or extensive engineering resources.
So instead of full access control, I’d happily settle for just following three nudging features which would solve over 90% of my use-cases:
-
Ability to prevent users from deleting any row except via a button action (the subject of this thread)
-
For any column not set via a formula: add a “Disable if” option that works just like it does for buttons: if the formula returns true for a given row, the user cannot edit the column value at that row. The value doesn’t get deleted and remains readable by other formulas in the doc, it just becomes uneditable.
-
A single column user-table that I can choose to insert in the doc, to which I can add columns and of which I can make views. Coda will automatically add one row per user with access to the doc, and I can choose to not sync deletions (ie users who leave the doc). Basically, very similar behaviour to cross-doc tables, except I get a “user” object instead of their “row” object.
I venture to say that with a bit of creativity, a Maker can leverage the existing formula language and the above three features to do pretty much all the nudging they need.
Sorry for the slightly out-of-topic rant.