I have suggested this previously, but it is so important that I am writing this once more.
The locking scheme of our plan works miracles to create a very powerful app like experience. We have quite a few options now that work very nice, except for one option: editing page text. I have that option generally turned off, so my layouts and content stay intact. It seems like the other options (adding rows, deleting rows, change table values, pushing buttons) work equally well on the the canvas of pages and on the objects of a table canvas column. But the canvas column canvas text is not affected by the locking options, meaning that a canvas column table can be wiped out by one accidental delete or backspace key touch, either by a unknowing or not tech savvy user of by myself when I don’t realize my active cursor is on an column canvas.
For me, a table is a table, regardless of where I am in Coda, so I am happy with the locking options pertaining to tables (on a regular page or on a column canvas).
Likewise, a canvas is a canvas, so I would like the locking options act the same on any canvas, regardless or where they are in Coda.
Could you please please please either
a) make the edit text locking option work on the canvas column canvas cells, or (better)
b) add another option for locking the editing text on the canvas of a canvas cell.
Thank you so much for considering this.
Use case: setting up filtered tables for storing program parameters, confidential text, etc. This currently works pretty good, other than the that you can’t protect your (canvas cell) pages against altering or deletion.
Hey @joost_mineur ! This sounds like a feature request the Coda team has been tracking for locking the canvas column as a separate table object. That said, we have moved this post into the Suggestion Box for other members of the Community to chime in on this. We’ve gone ahead and tracked your vote for this feature formally.
Thank you for noticing my posting. Since you invite ‘us’ to elaborate on the subject of this posting, I will add another comment regarding this subject.
Even though I have accepted the fact that Coda docs are not meant as a secure place for secret information, there is less secret stuff that needs some protection, like parameters used in formulas (such as tax percentages, defaults for making proposals, and many more. There are also tables in which you don’t want users to make changes.
We have a lot of options to accomplish most of this: table filtering and pretty fine grained page locking.
With the addition of canvas columns, coda has made it possible to store complete pages (or page templates) in a single canvas column row. Giving users access to canvas cells allows for large amounts of text, meeting notes, pictures and much more to be added in a single field (a cell in a row with property canvas).
Really fantastic, until you realize that when a user types /table in a canvas field. This user will be able to choose ANY table of your document, get rid of filters and show any (hidden) column. If you have a user table with user roles (with certain access rights): any user role can be changed as this users sees fit. But, worst case scenario: if this table is normally only available on pages that allow limited actions (no delete for example), it is all undone in the canvas column. You can wipe out an entire database if it pleases you by undoing a filter, selecting all rows and righclick and select delete.
Something seems to have changed of the last couple of days. I am pretty sure that locking options for a regular page were also in effect for tables on a canvas page - but that’s no longer the case.
Bottom line: unless you have a very small group of trusted people working in your doc, you can’t use canvas pages if you can’t afford to prying eyes or people performing unwanted actions on your data. Since regular Text fields can be used to store larger bodies of text, they are a short term alternative for canvas fields. But all the advantages of canvas fields (bullit lists, checklists, illustrations, tables) won’t be available in text fields.