Editing lookups from a locked, read only table (and how do we lock a lookup table properly!)

I wonder if I might be mis-understanding some of the locking features for tables.
I have a bunch of control tables all on one page. That page is set to read only, and that works as planned when on that page.
So - trying to edit any of these items :
Screen Shot 2020-05-28 at 10.06.47 pm

brings up this info box as expected.

Screen Shot 2020-05-28 at 10.06.54 pm

However, within the database table (which is on a page that is not locked / not read only) that looks up these control tables, I’m still able to edit the values.
The locking values for the db table are the following :

Here’s the earlier data from the control table as a lookup in the db table…

And… I can easily edit it by opening the modal…

This doesn’t seem to match the logic as I thought I understood it for locking.

Does this mean there is no way of locking down data if its a lookup from another table? Is this as intended by coda / have I gone about things the wrong way? Or is it a bug? Or… So many questions! :slight_smile:

Would love to hear how others approach this. It seems being able to lock down lookups is vital for the use of databases in business environments.

Cheres!

1 Like

I’ve seen another post which seems to imply that the behaviour I’m seeing is by design - but I don’t quite get it. (It is after all mentioned as a “loophole”.

Properly understanding will hopefully point me towards the best solution.

What I’m looking for is a way to lock the items which are listed for a lookup. Making the table which is looked-up read-only does not work as shown in the OP.

I’m beginning to think the best way is to simply go back to using select lists which are maintained in the column itself, rather than looking up another table. The table thing makes life MUCH easier to maintain - as well as seemingly better practice for data-management within the whole document. (Many tables can reference the same table!)

Am I explaining things well enough or should I try again? I’m pulling my hair out a little about this. I’m figuring others have come across this and must have found a way forward.

I’d really like to get to the bottom of this.

how do folk here design around this issue - or is it a non-issue and I’ve just not understood how to set things up properly?

Perhaps I can reframe and ask as a simple question.

Is there a way to have a lookup from a table where the user cannot change the options of the lookup?

After much playing around / trying different options out, it seems to me like the only way around this is to contain the options in a select list which isn’t using a table for the values.

Dear @Brendan_Woithe,

When it’s not allowed to add new options, you mean:

image

Thanks @Jean_Pierre_Traets
A gif probably shows the issue better than an explanation.

Hope this explains what I mean.

The main table (detail view) is what the user interacts with.
They select from a bunch of lookups.
However, it is very easy to accidentally open a lookup option, and change it. And once its changed, it effects all the data in the doc. This particular one is really obvious, but not all are. One of our staff accidentally changing something a few weeks ago broke things for them and we only realised 3 weeks later causing significant probs.

The allow quick adding of new items is off :slight_smile:

My question is what can i do about it? Seems odd I can change something that is in a read-only table.

2 Likes

Dear @Brendan_Woithe,

Thanks for the clear explanation :white_check_mark:

Looks like a bug :bug:, because when you hover with the mouse over it should NOT be allowed the “expand” to the options menu to edit
image

Dear @BenLee, your support on this will be appreciated :pray:

1 Like

Hi @Brendan_Woithe,
Sorry: I’m not giving any added value and I believe it is indeed a bug.
Due to its complexity, I think that the full Authorisation Roadmap in Coda is still a long way.

But I vote your gif the best explanation ever! :trophy: :grimacing:

2 Likes

I’ve only just got a decent gif recorder / discovered how powerful recording interactions with coda are!

And interesting to hear it might be a bug. Its a big one if there’s no way around it.

Hello @Brendan_Woithe ,

Just seeing this thread now. I believe it is designed to work this way, because the full record of any referenced row can be opened and edited. Often that is the desired behavior, but I agree that there are at least as many situations where you don’t want it to work like this.

I would urge Coda to add an extra option to the locking options:
If a page is set to read only, don’t allow records to change. You could then keep all your to be protected tables on one or a few read only pages, only to be unlocked by designated editors. Obviously, this will create a new set of design issues, because a lot of times you are editing records through a view or a button function and those won’t work for these tables.

A better solution is to create an extra user type (between editor and view only) with a setting for that user type to restrict ‘indirect’ editing through referenced fields, but be allowed to edit through views (if they have acces to the view) and through buttons. In my opinion this special usertype should also be granted/denied access to specific pages or folders.

This reply will bump the topic to the top - let’s see what happens.

Greetings,
Joost

4 Likes