Locking settings not (yet) implemented on canvas columns

Suggestion Box
1

Good morning Codans,

I make extensive use of page and/or doc locking. I noticed that the locking settings don’t inherent to canvas columns. Since the canvas ‘cell’ will, in many cases, be used like a child page of the parentrow, I would expect the Locking settings that apply to the page where the parent row came from inherit to the canvas column cell/page. Or, alternatively, that individual settings can be made on this level of to the entire column.

I realize that this is not a finished feature and just to make sure this is not overlooked I am posting this suggestion/bug report.

Let me assure you I am pretty happy with what we got so far though.

Greetings, Joost

3 Likes
2

Hi @joost_mineur, thanks for the feedback!

We debated whether expectations for canvas cells locking would more often mirror those for other cells in the table, or for the text on the page containing the table or view. We chose the former, but it sounds like in your case it’s the latter?

As you said, we also suspect some scenarios may need finer-grain control on the column itself, which we weren’t able to provide in this launch.

We’d love to hear more about your scenario and what content you do & don’t want to be editable. Specific examples are always helpful to clarify. If you’re not able to share publicly, feel free to also share as a DM.

Thanks!

3

Hey @nathan ,
Thank you for thinking (and having though) with me about these issues.

Considering the fact that the canvas column cells can (and will) be used like pages, I would be tempted to think we need the same type of locking scheme that is available for standard pages.

I can imagine that we are going to have very specific singel purpose tables in these canvas cells. I have build a small sample app where a canvas cell of one row holds some crucial user access tables, and another row holds some reports (also tables). It is kind of scary to know that a single (accidental?) CTRL-A DEL will wipe out all of your data.

I can’t share my doc publicly, but I have shared it with support and if you send e a PM with your preferred email message I will add you as a doc user so you can see for yourself why this is needed for a lot of usercases.

Greetings,
Joost

1 Like
4

just to add my +1 for the use case put forward by @joost_mineur above

locking the canvas cell just like locking a page is essential

max

5

I need this asap!!

6

I agree as well - Locking the Canvas is needed, locking permissions elsewhere in the doc should transfer over to a Canvas cell.

Say for example you have a table that is filtered to only show currentUser data. Currently if all pages are locked to interact only no one can change those filters.

Also, no one is able to change columns, delete columns, change formulas on tables, etc.

But with the Canvas column not having any locking any user even in INTERACT ONLY mode can come in and start deleting columns, changing formulas, and other doc-devastating behavior. Vote up for sure!

My humble letter to Coda

2 Likes
7

Hello @Scott_Collier-Weir ,

When canvas columns were introduced, I set up a doc with authorization levels - levels managed in a table on a canvas page. Only users with authorization level ‘admin’ have access to this canvas page - and therefore access to this user table.
For users, upon opening my doc, they have access to their own rows in different tables, as well as more general rows in other tables, based on their authorization level.
So far, so good.
Up to the point where you allow users access to a canvas row, regardless of which table or area of your doc has this canvas row. Nice for freeform notes, making their own tables, etc.
But, the moment they type /table, every table in the doc is exposed. They can add a view of any table to their private canvas row, including the document user table where an admin enters user authorization levels. Remove the filters, show all columns…and the user can change his authorization level, to whatever role, like ‘admin’.
Canvas pages have their value - even today. But in shared docs, they are a ‘disaster’ waiting to happen. If you make a dashboard on a canvas page, the entire contents can be deleted or manipulated. And text and table/views can be added at will.

So, for canvas columns, we need:

  1. the locking settings as we know them now
  2. with the additional options
    a) allow text and images (on/off)
    b) allow new (simple) tables (on/off)
    c) allow other controls (on/off)

This way we can give users acces to canvas pages to write long notes, add pictures and make (simple) tables. Why simple? Because you don’t want to allow lookup columns, or formulas to find things in other tables, to name just a few things.

And if Coda will make this for us, they might as well add the ‘don’t allow to delete rows’ option :-).

Obviously, makers should be allowed to make whatever canvas page they want.

I was not sure if I should outline my thoughts so explicitly, but I think makers need to know the consequences of using canvas columns, because as innocent as they look when used as a note taking page, it’s a wolf in sheep’s clothing.

Long story short: yes, I support your request to Coda.

Greetings,
Joost

5 Likes
8

I’d like to add my support also for this feature. Without this locking feature it is too confusing for users and simply just too easy for a user to “break” the page.

My use case is this. I am a life coach using canvas pages to build a message dialogue for a “micro-coaching session” where I can support the user with an asynchronous text-based coaching session.

9

I’ve searched the forum to see if it was on the roadmap but came with nothing.
Is there any status update from Codans about wether this feature is planned in the near future ?
This would really unlock nicer UIs without an user accidentally deleting everything.
These accidental deletions are actually becoming a pretty big source of stress, for canvas columns or for rows (we need a confirmation dialog !)

10

My solution for this has been to create two canvas columns for rows where I want to be able to show a locked canvas, and drive one (the locked canvas) with a formula that displays the other (the “edit” canvas). I create two views of the table, and create a nearly identical custom layout for each view (edit layout + locked layout). Usually these layouts have “show hidden columns” and “display comments” toggled off for consistency.

Then, if I want to provide only a display view to a user, I put that into their UI pages. If I want them to also have access to the edit view, I provide a dynamic button which leads them through an “Edit” and “confirm or cancel” workflow. This button leads the user back and forth between the display and edit layouts via their respective table views. In cases where I need a nondestructive edit capability and a history of edits, I create a 3rd “saved” column hold the current version while updates are being made - allowing a user to press “cancel” and have the button restore the pre-edit state from saved. I also create a parallel revisions table that stores each revision of the saved canvas after each edit.