Just to chime in on this, yes this is extremely important to have. Adding to this, it would be a great idea to restrict deletions so we could design buttons that delete a row in a way the developer wants to do it.
1 Like
Still interested in this. While I understand @BenLee ’s rationale that anyone you can trust to edit, you should be able to trust to delete, I think it misses an important difference in the impact of those two things.
When rows are edited (or even cell contents deleted) you have the Activity history pretty close at hand to untangle the issue (this happens fairly frequently in my heavily-used docs; misclicks, typing without realizing you’re selected on a certain cell, etc)
When rows are deleted, afaik the only way to see what happened and recover is via doc history. Wait for history to load (slowly, if large doc), find state containing historical item, clone new doc based on state, copy and paste row into main doc.
Inadvertently deleted rows are harder to detect and more cumbersome to recover from than inadvertent edits, so deletion should have its own permission switch.
9 Likes
The option to prevent users from deleting rows is sorely needed, without this the locking feature is essentially useless for our use case.
We want users to be able to EDIT rows, their own and rows added by others, they should NOT be able to delete any rows, even if created by mistake.
I understand that by being able to edit, they can essentially remove ALL CONTENT in a row, but still it would be an empty row and NOT a deleted row - empty rows are easier to detect and fix - looking for deleted rows in a large CODA doc is quite painful.
2 Likes
It’s been almost 3 years since this issue was first raised, and it still remains a major pain point for our us.
I appreciate Coda has been focusing on the editor upgrade and some amazing new features, but a small change like this one is low-hanging fruit and an easy win that will make many customers very happy.
3 Likes
My 2c on this.
For me, locking is not about “whom you can trust to edit” — locking is not about trust at all, it is not a security feature. Locking is about preventing accidental actions.
My biggest use case where I want to allow for editing but not deleting — helper tables where rows are strongly linked with the setup. E.g., I make a makeshift intake form and each row is an input. I want the user to fill out each input but not be able to (accidentally) remove questions from that form.
3 Likes
Yes, its not about trust or the assumption that my editors are coming with intent to delete everything - it is about not having the DELETE THIS ROW EVERYWHERE feature present right there in the context menu.
I think this needs to be pushed more - if this is something the community is asking for for years.
1 Like
BTW, have you found any work around for this issue ?
Well, the only way is to have another layer of helper tables over those tables that I want to prevent from being tampered with. E.g., there’s a DB table that cannot be directly edited, and there’s an intake form table that can — and there’s ultimately a button that would copy the data from one table into the database table, and the button wouldn’t work if something’s not valid.
1 Like
Thanks, this is maybe the same thing I was cooking up in my mind, but your words give it a more clearer image.
I got the team membership just to be able to lock and prevent the delete feature and now I am finding that the core thing which I needed is not there.
If it is not too much trouble, could you share a document with the work around you mentioned.
THANKS
I appreciate @BenLee 's response saying that current behavior was by design, but the granular permission structure that has evolved over many decades in the DB world is the way it is for a reason…
This was pretty much the same response we initially got regarding what now are called Personal Canvas Controls… Which EVERYBODY loves.
For Coda to scale into use scenarios that are more than a few friends, you need control as an admin.
IMHO - This is where Coda can truly differentiate itself from Notion etc… : be less “cute” and be a little more “enterprise”.
2 Likes
Granular permissions is something Coda is really behind (for a start on per page basis would be huge improvement, like Notion for example).
On the side note option to prevent people from unhiding hidden pages (when you lock the document for example) would also be cool and not that hard to implement, and prevent people from accidentally messing some of the “setup and background” tables and pages.
4 Likes
Ben, setting Change table values: OFF and Add Rows: ON causes me the doc maker to be unable to edit rows that I have created. Did this policy change? I would like to achieve the behavior where all the data is read only except for the rows that I myself have created. Thank you!
This hasn’t changed and I just tested it and I’m able to edit the rows I created.
Are you logged in with the correct account, the one that matches who created the rows?
My account matches the user who created the rows.
I as the creator can edit the rows I created but I cannot edit the subtables of the rows in the detail view.
Rows in a subtables are rows that are associated in some way with that particular row, but they aren’t actually sub-data of the row. Since they are their own rows, they will have been created by someone and the permissions for editing will be with that person.
You can add a column to that subtable and use the CreatedBy(thisRow) formula to see what accounts created them.
Hi Everyone,
First off I wanted to say we definitely appreciate all of the feedback in here, and sorry about the delay in addressing the feedback. We have been busy on a number of exciting fronts.
We are taking a look at if there is something we can do here that aligns with where we want to go directionally. (No promises yet).
Splitting “Delete Row” from “Change table values” seems to have universal approval in this thread 
The one thing I’d like feedback on is how “Add rows” should behave. Currently when you enable “Add rows” users are allowed to delete a row that they added. While we realize this might not be perfect in all cases it does prevent some ugly scenarios where you accidentally add a row that you can no longer remove. I think we would lean towards maintaining this aspect of locking behaviors. There is a work around here when you can enable adding rows using a button even while “Add rows” is disabled as long as “Use buttons, controls, and forms” is on.
5 Likes
if deletes are disabled then maybe allowing users to delete rows they have just added is maybe ok.
as long as they do so immidiately (ie before leaving the page/dialog or making further changes to other tables).
the main use-case we are trying to avoid is users being able to delete rows that are linked to other tables.
ie… deleting a Customer row and leaving lots of that customer’s Order rows as orphans.
so the maker can lock the ux to make sure the user can only make such additions and deletions by using the buttons they provide. those buttons then have appropriate logic to assert consistancy in the resulting data changes, such as preventing deletes of a Customer when Order rows exist for that customer. or ensuring that deleting a Project row causes a deletion of all the Task rows linked to that project.
i have had a great many instances where users delete things without realizing the damage it does to the consistancy of the whole data model.
max
2 Likes
Really glad to see this finally getting some attention!
Chiming in to say that as long as there is a way to prevent any row deletions except via buttons then I am one happy camper.
All my current docs have “Add rows” disabled, and I provide buttons for row creation in all pages with custom logic - so I basically default to using the workaround you mentioned.
1 Like
Hello @Jason_Tamulonis ,
Thank you for addressing this.
I understand your arguments, but should it not be to the doc maker to allow (or not allow) for your so called ‘ugly scenario’. And, just like it’s more or less said in the above postings, a doc maker can address any issue with buttons overriding the default settings.
I am comfortable with coupling add/delete options in one setting, but at the same time, these are two different animals.
As far as I am concerned either option (one setting for both or separate options) work fine and I think most everyone that is concerned about this will have a user interface with add (and delete) row buttons. We can already make these (delete) buttons function in such a way that a user has only x many minutes after creating a new row by putting a disable function in the button.
Looking forward to seeing this happen.
Greetings,
Joost
perhaps i can make the need more clear…
we need a locking regime where we can (if we need to) take control of adding, removing and editing rows in a workflow.
there are so many genuine situations where a workflow requires that these operations are under the control of buttons that enforce business logic. such business logic being unclear to the users of the workflow but vital to the consistancy of the underlying data model.
today we can do only some of that.
when i provide buttons for adding and removing rows, and then lock the page to prevent adding rows, the users can still destroy the data model by deleting rows anyway, leaving ‘widows’ and ‘orphans’ in other tables.
if i prevent edits but allow buttons, then, alas, any dialog brought up by OpenRow() etc, is ALSO locked to prevent edits - ie: dialogs need their own locking options (which could default to the page’s settings).
i accept that a great many situations are enhanced by the ‘standard’ ux behaviour, where users are empowered to add/delete/amend rows, columns, formulas etc at will.
thats fine when my users know and understand the underlying data model.
but my clients have users who DO NOT know nor care about the data model. but where the consequences of the users adding/deleting/amending ad hoc, rows, columns and formulas is damaging to the business.
we are not trying to turn Coda into an App Development tool - just looking for a SMALL set of additional features to protect our clients, users, workflows and data.
bus drivers, bakers, clerks, parents, sales people, etc, need to be able to safely use these workflows even though they are not power-users.
we are so close, just a tiny bit more, and we are there!
respect
max
5 Likes