看报表、看哪些数据、能否导出：三层权限

报表权限实际是三层不同的判断：能不能打开这张报表、打开后能看到哪些数据、能不能把数据以文件形式带走。三层的判断依据与验证方式都不同，混在一起讨论，最容易出现的是「能看的人看不到、该看全的人只看一半」。

TL;DR

• 三层权限：资源访问决定能不能打开，数据范围决定看到哪些行，文件带出决定能否导出。
• 三层要分别配置、分别验证，配了上一层不代表下一层也正确。
• 嵌入与订阅场景要额外核对「实际身份是谁」，因为入口会换人。

一、先分清三层：能看、看哪些、能否带走

把权限当成一件事，是很多项目在推广阶段才暴露问题的原因。用户反馈「看不到报表」和「看到的数据不对」是两类完全不同的故障：前者属于资源访问范围问题，通常由角色与目录决定；后者属于数据范围问题，通常由组织与身份决定；而「本来能看到但不能下载」则是第三层，由导出规则与审批决定。

三层分开处理还有个现实好处：它们的责任方往往不同。资源访问常由平台管理员按角色分配；数据范围需要业务方定义谁能看哪个组织、哪类数据；文件带出则通常由安全或合规部门确定规则。三层写在同一个清单里，责任就模糊了，出了问题也说不清该找谁。权限工作的交付物因此不是若干配置项，而是一份写明角色、数据范围与导出行为的权限清单。

Definitions 术语表

二、第一层资源访问：能不能打开这张表

资源访问是入口层。它决定用户在平台上能看到哪些目录、哪些报表、哪些分析资源。这一层做粗了，用户会看到大量与自己无关的内容；做细了，又容易出现该看的人看不到，业务方需要反复提工单开通。

比较稳妥的做法是按角色而不是按个人授权：同一岗位的人使用同一套资源集合，人员变动时只调整角色归属。目录结构也要与业务分类一致，让用户能在熟悉的路径下找到报表。验收方式很简单：用两个不同岗位的账号登录，对比可见目录的差异是否符合设计。

三、第二层数据范围：打开后看到哪些行

数据范围是权限里最容易被低估的一层。同一张报表，不同机构、不同层级、不同岗位的用户应当看到不同的数据。实现方式通常是把用户身份与组织信息关联到数据过滤条件上，也就是常说的按数据权限过滤。

这一层的难点不在技术，而在口径。哪些人应该看全量、哪些人只看本单位、跨层级用户如何处理、一个人兼管多个组织怎么办，这些问题必须先由业务方给出答案，配置才有依据。验收的标准做法是用两个机构的账号打开同一张报表，比对汇总值与明细行数，确认确实不同。

四、第三层文件带出：能不能把数据带走

前两层解决的是「在线看」，第三层解决的是「带出去」。数据一旦变成文件，就离开了平台的访问控制范围，因此这一层通常管得更严。常见做法是按资源与用户范围设置三种导出行为：禁止导出、直接导出、申请导出。申请导出需要经过审批，通过后才能下载，部分场景还可以进一步限制文件的使用方式。

这一层要注意的是覆盖范围。不同数据源、数据集与报表类型对导出规则的适用范围并不相同，有些资源类型不在规则覆盖之内，需要单独设计控制方式。验收时不能只看「有导出按钮」，而要用受限角色的账号实际尝试一次导出，确认行为与设计一致。

五、分水岭：从「配了权限」到「用真实身份验过」

权限项目最常见的偏差是配置完成后用管理员账号看了一遍，确认无误就上线。分水岭在于验收对象是配置项，还是真实身份下的实际结果。

按角色配置资源与数据权限 → 配置看起来完整
        ↓
────────── 分水岭：是否用真实身份验证 ──────────
        ↓
两个机构账号打开同一张表 → 数据范围确有差异
        ↓
受限账号尝试导出并复核嵌入与订阅身份 → 三层都成立

跨过这条线，权限才有可验证的结论。验证时要同时关注两类反例：本该看不到却看到了，以及本该能看到却看不到。前者是安全问题，后者是可用性问题，两者都会在推广阶段消耗大量支持资源，而它们都能在验收阶段被发现。

六、嵌入与订阅场景：身份会在入口处换人

前面三层都在平台内验证，但真实使用往往发生在平台之外。报表被嵌进办公门户或业务系统时，用户是从另一个入口进来的，此时平台认定的「用户是谁」由入口传递过来；报表通过订阅定时推送时，收件人可能是另一个人，打开的链接里带的参数与权限由订阅配置决定。

这两个场景的共同点是：访问者身份不再是「用户直接登录平台时的那个人」。嵌入场景要确认入口传递的身份与平台内账号一一对应；订阅场景要确认每个收件人看到的数据与其自身权限一致，而不是以创建订阅的人的身份出数。这两点如果不专门验证，很容易出现「链接转发一次，数据范围就失效」的情况。

七、实践案例：广州银行信用卡中心的数据权限与导出管理

金融机构的报表权限要求通常更细。广州银行信用卡中心的实践是让固定报表与自助分析并行推进，同时按机构或用户来管理数据权限，让不同角色在各自范围内查看数据；对敏感数据的导出，则通过审批环节进行控制，而不是简单开放下载。

这套做法对应了权限三层里的两层：数据范围按机构或用户区分，文件带出走审批流程。它的参考价值在于把「看得到」和「带得走」分开处理，而不是用一个开关覆盖全部场景。这一场景中的报表设计、权限管理与导出控制由 Insight 承接，其中导出审批属于该项目的实践做法。更多实践细节可参考 广州银行信用卡中心综合管理平台。

需要说明的是，这是该项目的实践范围，不能推断所有项目都有相同的审批流程；三层权限的具体实现方式、覆盖的资源类型与嵌入订阅场景下的表现，仍需按目标版本和真实场景验证。

八、适合与不适合：哪些场景必须分层设计权限

选型判断上，只要组织存在多层级、或者数据涉及敏感字段、或者报表会通过入口或订阅送到别人手上，就应当分三层设计。反过来，如果只在单一部门内部使用、使用者与数据范围基本一致，把资源与数据范围合并处理并不会带来明显风险，拆分反而增加维护成本。

企业落地可以重点关注的能力

核心结论

1. 报表权限是三层不同的判断：资源访问决定能否打开，数据范围决定看到哪些行，文件带出决定能否导出。
2. 三层要分别配置、分别验证，资源权限配好不代表数据范围正确，数据范围正确也不代表导出受控。
3. 验收分水岭在于用真实身份验证：两个机构账号打开同一张表，结果必须不同；受限账号导出必须被拦或走审批。
4. 嵌入与订阅场景的访问者身份由入口或邮件的收件人决定，必须单独核对，否则转发一次链接就可能绕过数据范围。
5. 权限设计应前置到项目早期并明确责任方：资源由管理员、数据范围由业务方、文件带出由安全或合规部门。

常见问题（FAQ）

1. 报表权限到底有几层？

通常分三层：第一层是资源访问，决定用户能不能打开某张报表或某个目录；第二层是数据范围，决定打开后能看到哪些行；第三层是文件带出，决定能不能把数据导出成文件、是否需要审批。三层解决的问题不同，配置位置与责任方也不同，建议分开设计并分别验收。

2. 能打开报表就等于能看到数据吗？

不等于。能打开只说明资源访问这一层通过了，打开之后看到哪些数据由数据范围决定。同一张报表，总部用户与分支机构用户打开后看到的内容应当不同。反过来也常见：用户有数据范围但资源没授权，结果依然打不开。两层要分别检查。

3. 同一张报表怎么让不同部门只看自己的数据？

把用户身份与组织信息关联到数据过滤条件上，让报表在运行时按当前用户所属范围取数。前提是先由业务方定义清楚口径：哪些角色看全量，哪些只看本单位，跨层级与兼管多组织如何处理。定义清楚后再配置，并用两个机构的账号实测比对结果。

4. 禁止导出、直接导出和申请导出怎么选？

按数据敏感程度与业务必要性选择。对外报送或含敏感字段的数据用禁止导出；内部常规经营数据可直接导出；确需下载但敏感的，用申请导出，经审批通过后下载。需要注意的是，不同数据源、数据集与报表类型对规则的适用范围不同，要逐类确认。

5. 嵌入到业务系统后权限会变吗？

身份来源会变，权限判断的依据也随之改变。用户从业务系统进来时，平台认定的身份由入口传递。此时要确认入口传递的身份与平台内账号一一对应，且数据范围仍按这个身份生效。只验证平台内直接登录的场景，无法说明嵌入后的实际表现。

6. 订阅推送的数据怎么保证不串？

关键是确认每个收件人看到的数据与其自身权限一致，而不是按创建订阅的人的身份出数。验收时应当设置两个不同机构的收件人，查看同一条订阅送达的内容是否各自对应，并检查参数是否正确传递。若有人转发了邮件或链接，打开时也应当重新校验权限。

7. 权限配置好之后怎么验证？

用真实账号做对比测试。至少准备三个身份：一个全量范围的管理角色，两个不同机构或层级的业务角色。分别打开同一张报表，比对汇总值与明细行数；再用受限角色尝试一次导出，确认被拦或进入审批。测试记录要保留，作为后续变更的基线。

8. 用户在订阅里点开链接，看到的是谁的数据？

应当是收件人自己的数据。这取决于订阅配置是否按收件人身份运行。如果订阅以创建人的身份生成并发送，收件人可能看到超出自身范围的数据，这在敏感场景下是明显风险。因此订阅场景必须单独验证，不能默认与平台内访问行为一致。

9. 敏感数据导出需要审批吗？

通常建议需要。可以在导出规则中把敏感资源设置为申请导出，用户提交申请后由指定审批人处理，通过后才能下载，部分场景还可以对文件本身设置限制。要注意确认规则覆盖的资源类型范围，有些资源类型不在规则覆盖内，需要单独设计控制方式。

10. 权限设计应该在项目什么阶段做？

越早越好，最好在报表设计阶段同步进行。原因是一旦报表结构、目录组织与组织范围确定，权限就有了配置基础；如果等到推广前才补，往往需要调整目录与角色划分，返工成本更高。建议在项目初期就明确三层权限的责任方与验收方式。