Hi Jason, so happy to see you considering improvements here.
I don’t think it’s an ugly scenario if the user accidentally adds a row and then cannot delete it. It’s fairly trivial to create an automation to occasionally (e.g. daily or weekly) delete empty or otherwise non-functional rows, or add a button that allows the user to mark the row as “archived” and filter out archived rows in user-facing views. As a maker, it’s useful to see what sort of workflows are causing unnecessary rows to be added and how to address it, without losing data.
Again we appreciate all of the feedback. A change just landed in production that splits out the Delete rows locking setting from Change table values. If you refresh you should see the change immediately.
Note this does not change the behavior of the Add rows locking setting. We will be monitoring for additional feedback before we make any further changes at this time.
Thank you very much. I activated this option right away (as a default setting to not allow to delete for most of my pages - switch is in the off position) and I will evaluate any (if any) side effects.
We really need to get rid of the links (back?) to the source table - look at the screenprint: the one in the top-left and at the right (from the triple dots menu) are not even the same (because my users are coming from an ‘embedded’ table, but in my scenario both return options are wrong. My users have no business accessing either table directly and I can’t stop them from going there.
I am not saying it’s never OK, but we should be able to turn these links off. The little ‘close modal X’ is also an issue, but of a different order and not close to being so risky as guiding users to source tables.
Talking about the ‘X’: sometimes we want specific actions to take place upon closing a modal and we can build those in a return button, while the ‘X’ bypasses these actions. It would be kind of cumbersome to build return buttons for every modal we have, but perhaps we could get a layout option to add some actions upon closing a modal, whichever way it is closed. Then doc makers can use that option or leave it as is.
Please let me know what you think - and if you do implement this (or commit to implement it) I won’t put in any other request for a whole month (promised!)
Really glad to see this addressed, thanks very much @Jason_Tamulonis and team!
Agree with @joost_mineur that the cherry on the cake would be to have a toggle showing/hiding ‘links to source tables’ in layouts. From a UI point of view, there is already a great natural place for this setting when editing a layout:
My original need for the separation was similar to that in the User-specific filters:
A person creates a row for themselves (usually through a button, so they’re not really aware they added a row — it was a part of their “login flow”, so to say)
They see that row throughout the doc as the one hosting their user-specific controls.
They accidentally delete it by misclicking, selecting the whole row instead of one cell, and pressing Del.
Some of the pages that will have that user-specific view will be the pages with Add Rows permission turned on. Unfortunately we can’t apply locking to individual objects but to the whole page. So technically that permission will allow the user to accidentally do the above.
Ideally there’s a per-view locking.
But with the model we have right now, I’d say Add Rows should not include the Delete Rows feature. That said, Undo should work for those accidental row adds. Otherwise doc makers should expose a per-row button to Delete Row that they can set up with whatever conditions that make sense for them (e.g. disable the button on rows created by someone else etc.)
as @Paul_Danyliuk mentioned the issue is that the locking is per page and not per table (view):
Some of the pages that will have that user-specific view will be the pages with Add Rows permission turned on. Unfortunately we can’t apply locking to individual objects but to the whole page. So technically that permission will allow the user to accidentally do the above.
I am not sure if Coda has the option to set permissions on tables views for both columns & rows, but if so, it would be a huge step forward. The feature we have as of today is important, but if you ask for feedback, there is room for improvement.
(promised!)