Editors can view table structure

[mathgim]

Describe the current behavior

Hello @dsagal,
I have seen your latest work on permitting editors to edit table structure. I have found out a weird thing with ACL for editors. Currently, editors, in some conditions, can see table structures even thoug we have not allowed them to edit table structure nor allow them to see any row from this table.

cc @hexaltation

Steps to reproduce

Here is a link of the Grist template I created for this issue.

The formula rec.id in user.Team.Main_Data is to me badly interprated by Grist core. This formula is used in a table rule to allow users to have access to specific rows and is used in addition with user.Access in [EDITOR] that I added in the by-default Grist file rule.

Some details of the template below:

1. ACL

2. Data

3. What Paul sees

Describe the expected behavior

Paul should not even see the "Main data" table as he has access to zero row. Specifically, Paul should see an empty Grist document

If a user has access to zero rows of a table, it should not be able to see the table structure.

Where have you encountered this bug?

• On docs.getgrist.com
• On a self-hosted instance

Instance information (when self-hosting only)

• Grist instance:

  • Version:
  • URL (if it's OK for you to share it):
  • Installation mode: docker/kubernetes/...
  • Architecture: single-worker/multi-workers

• Browser name, version and platforms on which you could reproduce the bug:

• Link to browser console log if relevant:

• Link to server log if relevant:

[dsagal]

I believe this is expected behavior. What prevents access in this case is the condition rec.id in user.Team.Main_Data. This is a per-row condition -- the list of rows visible depends on the data. As data changes, rows may appear or disappear, but the table and its columns (the metadata) shouldn't appear or disappear based on values in the records.

Grist does hide metadata when a rule is independent of the rows. If entire tables or entire columns are inaccessible to the user (regardless of the row contents), Grist does censor the affected metadata.

[mathgim]

Thanks @dsagal for the quick reply. I see what you mean by "the table metadata should not appear and disappear" but I do not have the same point of view. In many use cases I face, not being able to see any row means you're not granted to have access to this table. It means you are not considered such a role to have to take care of this. However, when I want to grant access to this table to this user, I want it to be as simple as adding it to a specific row. That's the reason in the file main rules, I prevent editors to see anything. In other words, by default, editors can't see anything and depending on where they are mentioned, they can see table structures and data. It would make sense in the latest release on preventing editors to edit table structures, to have also a boolean to prevent them to see table structures in which they have no data access. Last way of rephrasing it: let say, I give access to tables using team roles (a specific column in my user table). If Role1 has no access to Main Data table, the user won't see this table structure. As soon as I change its role, it would be able to see the table structure. It should be the same as if this user has no row access and from a sudden is granted to one of the rows. I hope I was able to express myself clearly. Thanks again for the hard work! Math

…

________________________________ From: Dmitry ***@***.***> Sent: Tuesday, 16 June 2026 06:27:23 To: gristlabs/grist-core ***@***.***> Cc: Mathieu ***@***.***>; Author ***@***.***> Subject: Re: [gristlabs/grist-core] Editors can view table structure (Issue #2395) [https://avatars.githubusercontent.com/u/1091143?s=20&v=4]dsagal left a comment (gristlabs/grist-core#2395)<#2395 (comment)> I believe this is expected behavior. What prevents access in this case is the condition rec.id in user.Team.Main_Data. This is a per-row condition -- the list of rows visible depends on the data. As data changes, rows may appear or disappear, but the table and its columns (the metadata) shouldn't appear or disappear based on values in the records. Grist does hide metadata when a rule is independent of the rows. If entire tables or entire columns are inaccessible to the user (regardless of the row contents), Grist does censor the affected metadata. — Reply to this email directly, view it on GitHub<#2395?email_source=notifications&email_token=AOK7FD2Y2KZNEBQQVB7CHOD5ADECXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZRGQ4TQMBWGEY2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4714980611>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AOK7FD3QCFS7E7XGXT5ZHY35ADECXAVCNFSNUABFKJSXA33TNF2G64TZHMZDMNRQGMZTGOJVHNEXG43VMU5TINRWGY2DMNBSGM22C5QC>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS<https://github.com/notifications/mobile/ios/AOK7FD2S3HDPZ5GZD6H47Z35ADECXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZRGQ4TQMBWGEY2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android<https://github.com/notifications/mobile/android/AOK7FD5A43VEMCTG6LAY65L5ADECXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZRGQ4TQMBWGEY2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[dsagal]

You can do that using conditions that use user attributes. For example, if your Users table had a Toggle column "Main_Data_Access", you could grant or deny access to "Main_Data" table based on a condition like user.Team.Main_Data_Access == True. Changing that one toggle would show or hide the entire "Main_Data" table for that user.

The difference with your example is that the condition does not mention rec, and access depends on data in the user-attributes table, rather than in the table being filtered by the rules. Note that changes to the user-attributes tables will trigger a reload of the document for all connected users, precisely because Grist knows such changes may affect what metadata users are allowed to see.

[mathgim]

Indeed, this can work on addition with the use of rec to filter to specific rows per user. But I see two problems: 1. If a user is an editor but is not in my user table, I need to complexify the formula to include this case 2. Having this toggle column being a formula calculated if the user is being mentioned in at least one row of my main data will require quite some ressources to be computed at every main data change.

…

________________________________ De : Dmitry ***@***.***> Envoyé : mardi, juin 16, 2026 1:48:24 PM À : gristlabs/grist-core ***@***.***> Cc : Mathieu ***@***.***>; Author ***@***.***> Objet : Re: [gristlabs/grist-core] Editors can view table structure (Issue #2395) [https://avatars.githubusercontent.com/u/1091143?s=20&v=4]dsagal left a comment (gristlabs/grist-core#2395)<#2395 (comment)> You can do that using conditions that use user attributes. For example, if your Users table had a Toggle column "Main_Data_Access", you could grant or deny access to "Main_Data" table based on a condition like user.Team.Main_Data_Access == True. Changing that one toggle would show or hide the entire "Main_Data" table for that user. The difference with your example is that the condition does not mention rec, and access depends on data in the user-attributes table, rather than in the table being filtered by the rules. Note that changes to the user-attributes tables will trigger a reload of the document for all connected users, precisely because Grist knows such changes may affect what metadata users are allowed to see. — Reply to this email directly, view it on GitHub<#2395?email_source=notifications&email_token=AOK7FD2OVUEAUQXFLRCCV6D5AEXYPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZRHAZTQNZZGA22M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4718387905>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AOK7FD34WRKWGT5W62VCNF35AEXYPAVCNFSNUABFKJSXA33TNF2G64TZHMZDMNRQGMZTGOJVHNEXG43VMU5TINRWGY2DMNBSGM22C5QC>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS<https://github.com/notifications/mobile/ios/AOK7FD67SEHM4O5GNLEOQ5D5AEXYPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZRHAZTQNZZGA22M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android<https://github.com/notifications/mobile/android/AOK7FD32N5A3ZZS3GH2KVLD5AEXYPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZRHAZTQNZZGA22M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.

[dsagal]

In your case, you could add Main_Data_Access column to the Users table with the formula bool($Main_Data) -- so that any empty list is False, and any non-empty is True. Then you could have two rules for the table "Main Data":

• if not user.Team.Main_Data_Access -- "Deny all" (this will hide the entire table when a user doesn't have access to any rows)
• if rec.id in user.Team.Main_Data -- "Allow read" (for users who do have access to something, it will filter for only those rows)
  And a default:
• if user.Access not in [OWNER] -- "Deny all" (the default rule in your screenshot only denies editors, but does not affect viewers)

I imagine that the two Reference List formulas in your screenshot are two-way references, so Grist would already be keeping them in sync, and so I don't think you'd need any additional complex formulas.