为 Grist 文档设置并验证行列级访问规则

把 Grist 文档共享给协作者时，可以把对方设为 Viewer、Editor 或 Owner。但实际业务往往更细：配送人员需要地址和电话，不需要财务表；采购人员需要物品信息，却不必看客户地址；某些人只能处理当前阶段的订单，也只能完成特定的状态转换。

访问规则把这些限制落实到表、列和行。本文完整译写 Grist 官方 Access rules 指南，以采购与配送协作为主线，保留启用、禁用、特殊权限、用户属性、引用、状态更新、链接密钥和验证步骤。原页面没有个人作者署名，也没有固定产品版本号；本文核对的是 2026-10-05 可读的官方帮助页。规则与操作仅经过静态审查，本次没有连接或修改任何 Grist 文档。

先了解基本角色与启用后的变化

在分享菜单的 Manage Users 中，可以邀请 Viewer、Editor、Owner，也可以按需开启公开查看或编辑。只有文档 Owner 能修改访问规则。Owner 可以从左侧的 Access Rules 入口打开规则页，也可以从 Manage Users 中选择 Open Access Rules。

原文假设我们经营一家采购、配送特殊物品的小公司，文档包含 Orders 和 Financials 两张表。现在要让更多员工协作，但只把工作所需的数据和操作交给他们。

没有启用访问规则时，文档协作者可以看到文档内全部数据；Editor 与 Owner 在文档内都能更改数据、结构、公式和布局，包括创建或删除表列、编辑公式、重排页面。启用访问规则后，默认只有 Owner 保留修改结构的权限，Editor 失去此权限；完整复制和下载也默认仅限 Owner。

点击 Enable Access Rules，阅读说明并选择 Continue 后，会进入规则配置页。此时顶部 Save 按钮可用，意味着更改尚未生效。必须点击 Save，启用及后续规则编辑才会应用。

要禁用规则，需要先手工删除可删除的规则。若底部没有 Disable Access Rules 按钮，就继续通过垃圾桶图标移除其他规则；没有可删除规则后，禁用按钮才会出现。禁用会恢复更宽的默认能力，应在清楚业务后果时操作。本文只解释该入口，没有执行它。

规则按什么顺序决定权限

默认规则反映基础角色：Owner 与 Editor 可读写数据，Viewer 只能读，其他用户没有相应访问权。这组基础规则不可直接修改；更细的限制通过在它们之前添加规则实现。结构权限是后文单独说明的文档级权限，不能从这里的“可读写数据”推断 Editor 仍可编辑公式。

对某一项权限，先检查列专属规则，再检查整表规则，最后回退到默认规则。每组规则内部自上而下，遇到第一个适用且明确允许或拒绝该权限的规则，就得到决定，后面的规则不再改写这个决定。某一行规则未设置的权限，可以继续向后寻找结果。

组内最后一个空条件在界面中显示为 Everyone Else，总是匹配；写成 True 的条件也总是匹配。常见条件如下：

user.Access == EDITOR
user.Access != OWNER
user.Access in [VIEWER, EDITOR]
user.Access not in [EDITOR, OWNER]

它们分别表示 Editor、非 Owner、Viewer 或 Editor，以及既非 Editor 也非 Owner。这些是 Grist 访问条件，语法来自受限制的 Python 子集，不能当作任意 Python 程序使用。

把财务表限制给 Owner

在规则页点击 Add Table Rules，选择 Financials，创建这张表的规则组。新增条件：

user.Access != OWNER

把 R、U、C、D 全部设为拒绝，或从权限菜单选择 Deny all，然后保存。这样，非 Owner 的请求会在财务表规则处被拒绝，Owner 则继续由适用规则获得访问。

接下来可以把配送员工按 Editor 角色邀请到文档中。原文示例中，对方在侧栏里看不到 Financials，直接尝试打开它也会被拒绝。这里的关键是规则拒绝了数据访问，不只是让某个页面不显示。

如果每张表都要显式给 Owner 完整权限，可使用 seed rules。默认规则上方有一个快捷复选框，可在以后新建表规则组时自动加入 Owner 全权规则；展开 > 可以编辑种子规则。它用于减少重复配置，配置后仍应检查实际新建的规则组及其顺序。

先按个人限制列，再抽象成团队角色

配送人员 Kimberly 在示例中使用账户 kiwi@getgrist.com。假设她不需要看 Email 和记录包裹内容的 Piece 两列：先为 Orders 新增表规则组，点击组内三点菜单，选择 Add Column Rule，在 COLUMNS 的 [Add Column] 中选中这两列。

user.Email == 'kiwi@getgrist.com'

对这个条件关闭列规则中所有可用权限，也就是 R 与 U，然后保存。原文同样为采购人员 Charon 限制 Address 与 Phone。这里的邮箱是原文虚构业务示例，不代表已经邀请了真实用户。

人数增多后，逐个邮箱写规则难以维护。可以新建 Team 表，包含 Email 和 Role 两列，Role 使用 Sourcing、Delivery 两个选项。之后在访问规则中选择 Add User Attributes：

1. 属性名称设为 Team，这是以后在条件里引用的名字。
2. 来源表选择同名的 Team 表。
3. 用户属性用 user.Email，匹配表中的 Email 列。
4. 保存后，通过条件自动补全确认 user.Team 已可用。

现在 user.Team.Role 就能读取匹配行中的 Role，把个人规则推广为：

新员工加入时，只需按共享流程授予文档访问，再在 Team 中维护对应邮箱与角色。原文通过 Charon 的视角确认采购人员看到的是预期列。

本文静态审查补充：Team 是授权依据，应保护它的写入、创建和删除权限。如果员工能修改自己的 Role、替换邮箱映射或新增另一条映射，就可能改变授权结果。至少对 Team 的非 Owner 用户拒绝 U、C、D；R 是否开放按业务需要决定。同时检查邮箱映射的唯一性、未匹配用户和空角色的结果。这是原教程角色表步骤之外应补齐的生产配置，不是声称原示例已验证这些情况。

按订单阶段控制可见的行

订单从采购阶段进入配送阶段，两组员工通常不必同时看到所有订单。在 Orders 中新增 Stage 列，使用 Sourcing 和 Delivery 等状态。然后通过三点菜单选择 Add table-wide rule。

原文采用先封闭、再开放所需访问的思路：给非 Owner 设置默认拒绝，并在它之前放置符合角色与阶段的读取规则。注意以下是整表规则组的自上而下顺序，不是随意排列的两个条件：

rec 表示当前记录，可以读取本行字段。角色与订单阶段相同，则允许读取；否则非 Owner 落入拒绝规则。把第二条拒绝规则放在第一条之前，会使应开放的读取机会永远到不了，这也是为什么必须审查顺序。

如果 Owner 没有对应的 Team 记录，可把明确允许 Owner 的规则放在该组首位，避免先求值依赖 Team 的条件。这与前述 seed rules 的用途一致；仍需检查列级规则是否对 Owner 另有限制。

此时采购人员只看到采购阶段订单，配送人员只看到配送阶段订单，而且都只有读取权限；Owner 继续保留相应完整操作。前面列专属规则中的明确拒绝仍然先于整表读取规则判定，所以允许读一行并不自动允许读该行被限制的所有列。

访问条件里的引用是记录 ID

普通 Grist 公式支持沿引用继续取字段，例如 $Person.Email。访问条件中的 rec 并不支持直接沿引用取得其他记录，因此不能照搬 rec.Person.Email。在这些条件里，一个引用值通常是被引用记录的数值 ID。

假设 Orders.Purchaser 引用 Team，而 user.Team 是前面设置的用户属性记录。判断当前用户是不是采购人，可以比较：

rec.Purchaser == user.Team.id

左侧是引用记录 ID，右侧是用户属性记录的内置 id。如果 Orders 与 Team 都有指向 Departments 的 Department 列，则可比较：

rec.Department == user.Team.Department

两边都是同一目标表的记录 ID。若这样还不足以表达业务条件，可先在实际表里加辅助公式列，例如 Orders.Role 用 $Purchaser.Role 取到角色，再在规则里引用 rec.Role。这种辅助列同样要纳入可见性审查，不能把敏感数据通过公式列意外暴露出去。原页还提供了引用列访问规则视频作为延伸说明；本文不嵌入或运行视频。

只允许 Delivery 变成 Done

现在配送人员需要完成订单，但不应该任意修改 Stage。给 Orders 新增一条针对 Stage 的列规则，只把 U 设为允许，条件同时检查用户角色、变更前和变更后的状态：

(user.Team.Role == 'Delivery' and
  rec.Stage == 'Delivery' and
  newRec.Stage == 'Done')

rec 是变更前的记录，newRec 是拟议变更后的记录；newRec 可用于创建和更新时的条件。三项必须同时成立，才允许这次 Stage 更新。其他情况继续交给后面的限制规则处理。

原文用 Kiwi 的视角演示：从 Delivery 改成 Sourcing 被拒绝；改成 Done 则成功。变成 Done 后，这条记录从配送人员的视图消失，因为它已不再满足 user.Team.Role == rec.Stage 的读取条件。消失是读取规则产生的预期结果，不代表记录被删除。

测试时还应检查同一次操作是否试图改其他字段、改已完成的记录或创建新记录。只对 Stage 的 U 开放这一例外，不能被解释为授予整行任意更新、创建或删除权限。

特殊规则里最值得谨慎的是结构权限

默认规则下方有几项文档级特殊规则，每一项都有复选框以及可展开的详细条件。必要时可以按用户子集调整，但要理解它改变的是哪一种能力。

允许 Editor 修改结构。该选项恢复未启用规则时的结构编辑能力，以 S 表示。若没有任何表规则，且只有这一项恢复了默认行为，其效果相当于禁用访问规则。S 能创建或修改公式，而公式计算本身不受访问规则限制。掌握结构权限的人可能写公式读取文档中的其他数据，因此 S 可以成为绕过数据隔离的途径；限制敏感数据时，不能同时把它轻易交给受限协作者。

允许所有协作者查看访问规则。默认只有 Owner 能看规则；这个选项开放查看，不允许非 Owner 修改。不要把“能看配置”混同于“能改配置”。

限制非 Owner 完整复制或下载。只有允许非 Owner 查看规则后，相关选项才出现。完整副本包含规则，新副本的 Owner 可以看到它们，所以查看规则是完整复制的前提之一。即使某非 Owner 能读取全部数据，默认仍限制其复制或完整下载，需单独取消这项限制。没有全部数据读取权限的人，通常仍不能复制或下载整个文档。

模板复制例外。更深一层的展开区有特殊选项，允许受限用户复制或下载文档，用来演示带访问限制的非敏感模板。它的目的就是为了模板用途绕过读取限制，因此不适合敏感业务文档。原文还说明：用这个例外制作的副本不会继承该例外开关。

用链接密钥共享一个小范围的数据

有时只想把某一订单的信息通过链接交给对方。Grist 将 URL 中以单个下划线结尾的参数暴露给 user.LinkKey，取值时去掉参数名末尾的下划线。例如：

...?Token_=xx-xx-xx-xx&Flavor_=vanilla

条件中可读取 user.LinkKey.Token 与 user.LinkKey.Flavor，其值分别为示例中的代码和 vanilla。链接密钥只在网页客户端可用，不适用于 API。

要为每个订单生成难以猜测的标识，可以添加 UUID 列，先用 UUID() 公式生成值。UUID 不应随着公式重算不断改变：把公式列转换为数据列，冻结已有值，并保留触发公式，设为只应用于新记录。这样每条新订单生成一次标识。

再增加一个超链接列，通过 SELF_HYPERLINK() 把 UUID 放入 URL，原文还用 Ref 控制链接显示文字：

SELF_HYPERLINK(LinkKey_UUID=$UUID, label=$Ref)

将该列类型设置为 Text 并启用 HyperLink 显示。LinkKey_UUID 生成名为 UUID_ 的 URL 参数。UUID 与 Ref 列可以在界面中隐藏以保持整洁，但“隐藏列”本身不是访问控制，也不会让拿到链接的人失去使用密钥的能力。

订单的读取规则需要把 URL 中的值与记录中的 UUID 匹配。下面把原文描述整理成可审查的规则顺序；这是独立的链接分享场景，不应不加分析就叠加到前面的员工阶段规则上：

官方延伸的 Link keys guide 明确指出，面向未受邀收件人的链接分享还需要在 Manage Users 中设置相应 Public Access。链接参数不会凭空让一个完全不可打开的文档变成可访问。该共享方式会改变文档入口权限，必须在完整规则检查后按业务需求决定；本文没有替任何文档开启公开访问。

本文补充边界：这类链接具有持有凭据即可使用的性质，不应该使用可预测的订单号来代替随机密钥。保证 UUID 非空且唯一，检查缺少、错误及被转发的密钥分别会发生什么，并保护 UUID 列的写权限。只要密钥仍有效，转发链接可能把相同的读取能力交给其他人；撤销时应改变对应授权依据或密钥，并重新验证。不能把 URL 里出现一个随机字符串当成完整的身份验证。

链接密钥还可以关联多表、多行，或参与用户属性表映射；相应数据可以呈现在表格、卡片、卡片列表、图表和自定义组件中。它改变的是数据访问范围，不局限于某一种界面组件。

条件变量、允许的运算和错误提示

官方文档列出以下常用 user 成员：

rec 给出当前行状态，使规则能够按记录决定可见性或修改权；newRec 给出创建、更新所提出的新状态。条件支持字符串、数字、列表和这些变量的成员访问，原页列出的运算符包括：

and  or  +  -  *  /  %
==  !=  <  <=  >  >=
is  is not  in  not in

不要因为语法看起来像 Python，就假定任意函数调用或跨表查找都可用。如果条件子集不足以表达需要的逻辑，可以把合适的计算放在表的公式列中，再在规则里使用结果，同时审查该辅助列及结构权限。

规则支持 # 或三引号形式的注释。导致操作被拒绝的规则中的第一条注释可作为拒绝原因提示。更直观的做法是点击条件右侧的 memo 图标，填写给用户看的说明并保存；当规则阻止操作时，说明会出现在通知里。错误提示应解释允许的业务动作，避免泄露对方无权知道的数据。原页以限制重复记录为例，并链接到对应指南。

用 View As 验证，别把预览当沙箱

Owner 可以从 View As 下拉菜单选择协作者，文档会按对方视角重新打开，并显示醒目标记。例如选择 Kiwi 后，应该看不到 Financials，也看不到 Email 与 Piece；在阶段规则生效后，只能看到配送阶段订单。

还应进入 Raw Data，检查实际暴露的表、列、行与预期一致。只检查某个页面隐藏了什么是不够的，因为协作者可能从其他入口访问同一数据。完成后点击绿色的 View as Yourself，返回本人视角。

View As 不是沙箱。Owner 并没有变成那个协作者；在预览中执行的修改仍会改动真实文档，且记录为 Owner 本人的操作。因此要验证写权限，宜先使用无敏感信息的测试副本或明确的测试记录。下面列的是本文建议的验收场景，不是本次已完成的测试结果：

把“能做的事”和“不能做的事”都验证一遍，才能确认业务权限真正落到规则里。每次变更后先保存，再重新以相关角色检查；不要把本篇静态推演替代目标文档上的实际验证。

原文中的延伸示例

官方指南还收集了完整模板与案例：Lead list 将线索分配给个人并由 Owner 管理分配；Account-based Sales Team 区分销售代表与经理的数据范围；Public Giveaway 面向未登录参与者执行领取规则；Simple Poll 限制每位访客一次回应；Crowdsourced List 区分版主与普通贡献者；Time Sheets 让承包商查看历史工时、只编辑当前月份；Project Management 按部门与管理职责扩展权限。本文保留这些原文参考入口，没有复制、登录或修改任何模板。

来源与改写说明

原文：Grist Help Center — Access rules，Grist 官方帮助文档，未见个人署名和首次发布日期。本文用文字、规则表和自绘技术图重新呈现原文操作，保留公式与限制；补充了 Team 与 UUID 写权限保护、缺失映射检查、链接转发边界和验证矩阵。公开链接入口的前提另以官方 Link keys guide 核对。

来源为 Grist 官方帮助文档；原文与原图归 Grist 及相应权利人所有。软件开源许可证不自动等同于帮助文档转载许可。正文所有权限公式仅静态审查，没有宣称目标文档通过运行验证。