Skip to content

守卫单语缺口:「内置共享规则表」口径规则只读英文页,三语的另两份表无人检查 #809

Description

@yinlianghui

在实现 #790 + #791 时发现,作为观察记录立单,不在该 PR 里顺手改 —— 那次的守卫扩面已明确限定为 OWD 表(全对象集)与相关列表表(中文两页),把第三条规则一并扩掉属于判据变更。

现象

test/sharing-coverage.test.ts 有三条读文档的口径规则,全部读常量 SHARING_DOC(英文页):

  1. the built-in rules table lists exactly the shipped sharing rules
  2. every documented rule states the object, access level and position it really grants
  3. the related-list table tells the truth about each account child

#790 的 PR 把第 3 条按语言另立了一份(describe('the related-list table names the same account children on the Chinese pages')),并把 OWD 表守卫扩到三语全对象集。第 1、2 条仍然只看英文页。

content/docs/administration/sharing-and-security.zh-Hans.mdx:87-95.zh-Hant.mdx:87-95 各有一份同样的九行内置共享规则表,规则名是英文(Account Team Sharing 等),但对象列与授予列是翻译过的客户 / 客戶编辑 / 編輯读取 / 讀取)。今天这两份表逐条核对下来与 src/sharing/ 一致 —— 九条规则、对象、访问级别、岗位全对。

为什么现在不是活的缺陷

上面这句是实测:本单立单前把两份中文表与 src/sharing/index.ts 逐行比过,零漂移。所以今天没有读者会踩到假规则表 —— 这是休眠的覆盖缺口,按 observation-class 归类(finding,不带 pm:queue)。

它值得记下来的原因与 #725 一样:这一类缺陷在本仓历史上真的以中文页形态发生过(#791 的整页口径漂移、#592 漏掉的 | Events | 行都是),只是碰巧这张表干净。下一次有人增删一条 sharing rule,英文页会被守卫逼着改,两份中文表不会。

可选的修法

#790 落地的 PAGES 表已经是「按语言 authored 的 RegExp / 字面量」这一套基建,ROW_LABEL 里也已有全部 17 个对象的三语标签。所以扩第 1、2 条只需要:

  • 规则名列:语言无关,直接复用;
  • 对象列:查 ROW_LABEL[rule.object][locale],已有;
  • 授予列:新增一张很小的 ACCESS_WORD: Record<Locale, Record<'read' | 'edit', string>>
  • 岗位列:反引号里的岗位名语言无关,直接复用现有断言。

即一张三行的新 ledger,不引入新风格。

Related: #725(同形状,docs-drift.test.ts 的磁贴散文规则)、#791

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions