There’s a separate option to lock adding rows, but for some reason there is no option to prevent deleting rows and still be able to edit existing rows. The “Change table values” toggle locks both editing and deleting.
Need to be able to lock the section so that displayed cells can be edited, but nothing can be added or deleted.
Example:
I want to be able to change values in the “control” table and edit the snapshot name, but prevent users from deleting rows from the report (which are globally reused):
The current way things are working was a conscious decision so I’m not sure we’ll be changing it soon. The idea is that if a user can add/edit rows, they can also delete the rows they’ve added. They cannot delete rows others have added.
If you’re seeing a different behavior here, please report back and let us know.
Also, if there are use-cases you have in mind that we can research more where not allowing any deleting of rows is beneficial, it would be good to have that conversation here.
You have assigned some important tasks to your teammates. They can only mark the task as completed or dropped. If they delete the task, you have no idea which task was deleted.
Some users are not good at computer or mobile app and they only fill in simple data but not deleting the row.
A helper table to house a lot of complex formula and button which should not be put inside the data table. The row in helper table should not be deleted.
I would like to have the locking option for delete row. It only hide the delete button in right click or menu but you can still use a button to delete the row if you really want. At least you can use a button with “disable if” to have more control on what should be deleted.
In my opinion, the best approach would be to have standard permissions at object level (none, read, write, execute, delete).
Ideally up to the row granularity, but also at table level would work.
None: object not visible/accessible
Read(-only): allow to see data
Write: allow to change data
Execute: allow to manually trigger actions (i.e. buttons)
Delete: remove data.
It’s nothing new and - for this reason - more intuitive.
Also, from a UX perspective, it would be helpful to see the Current User’s (and eventually groups) permissions on the object itself (colour, pop-up letter, info box, etc).
I’m sure it’s far from being an easy implementation, but it’s a good way (the only one?) to have very consistent document authorisation setting.
The option only hide the “Delete row everywhere”. It should be relatively easy to implement. User can still use “DeleteRows()” to delete it with a button.
Hi! A solution to this is sorely needed for our workflow. This happened today in a project - a goal was missing and it’s only by chance I noticed it. I’m now digging through history to try to find it.
I have locks on and restrictions to only edit existing rows and we really need a way to make it difficult to delete things. It’s very easy to be focused on the wrong window and hit delete in the wrong app!
I really hope the Coda team can reconsider the current behaviour as it’s making doc locking basically useless for our purposes.
I have users who’s role is to just edit some rows added by someone else and they should not under any circumstance be allowed to delete the row.
example: Our finance person has to go into a “marketing agreements” table which is maintained by the marketing team. He role is only to mark the agreements as paid and edit the payment date. she has on occasion accidentally deleted rows and only realised it weeks later (by having the entire row selected and hitting backspace because she mistakenly thought the focus was elsewhere).
Sometimes it’s good to make it difficult for even the row creator to delete a row: for example a member of the marketing team who created an agreement row in the “marketing agreements” table, should be prevented from deleting the row if that agreement is marked as paid.
Frankly, the “delete row” behaviour in doc locking should simply be mirror of the existing “add row” behaviour as mentioned above by @David_Chung : I should have the option to prevent users from deleting any row except via a button action, in the same way that I can currently prevent them from adding any row except via button action. This should not depend on who created the row.
The current interface, where “Change table values” actually means: “Change table values and delete any rows” is asymmetrical, confusing, and not helpful in most use cases.
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.
I have tables where rows are allocated a reference number by formula. The ref number is more informative than a random or sequential number, but relies on a non-destructive approach. I have added buttons to mark a row as ‘deleted’, which just filters the row out and eventually and data contained will be wiped or replaced with place holder text to comply with our data policies. The important thing is that the row itself always needs to be retained. If an ‘interact only’ level user can really delete a row, the process breaks.
Im trying to figure out how to get around this problem as I don’t want a build up of empty or stagnant rows, but don’t have a solution to that yet. However, the proposal above by @David_Chung, where deletion can be turned on and off, in the same way adding rows can be, would be a great feature.
I’m upvoting this request as it is asymmetrical and breaks some workflows and is error prone with non tech savvy users. It’s really easy to accidentally select the whole row instead of a cell. Preventing row deletion would solve a few edge cases we have. A simple “Delete rows” switch in the locking menu would do the trick.
It’s been over 2 years since this was suggested. This is pretty core functionality that’s missing. Can Coda focus more on these important items rather than on things like a random-number-generator?
Please add this Coda. I consistently need to track down accidentally deleted data and those are just the ones that I know about, what’s worse is some (most?) of them probably go unnoticed. And this is with relatively small teams.
Also please add locking for the page navigation section so that people can’t reorder or it delete pages easily.
I really hope to see a push on permissions and privacy this year to address issues like this.
