权限模型

权限相关问题最容易在“我以为会这样”与“系统实际按另一套规则工作”之间产生误解。这页专门回答几类高频问题：公开链接、数据权限模式、行权限建模，以及平台/租户之间的授权边界。

为什么“使用者”模式不能开公开链接？

因为公开链接的前提是“任何拿到链接的人都能直接看”，而使用者模式的前提是“按当前登录用户身份决定可见数据”。

一旦访问者无需登录，系统就无法知道“当前用户是谁”，也就无法按使用者身份去裁剪数据。因此：

• 应用作者 / 数据集作者 这类结果固定的模式，可以支持公开链接
• 使用者 这种依赖登录身份的模式，不支持公开链接

相关说明可参考：

• 公开链接
• 权限控制

应该怎么选“应用作者 / 数据集作者 / 使用者”三种模式？

可以先按这个判断：

模式	适合场景	不适合场景
应用作者	希望所有访问者看到完全一致的数据结果	访问结果必须跟当前登录人变化
数据集作者	最常见，也最稳妥；适合共享分析结果	需要严格按当前人权限动态裁剪
使用者	必须按当前登录用户权限返回数据	需要公开链接，或需要开启加速引擎

如果多人协同分析，通常更推荐 数据集作者，因为结果更稳定，也更容易排查“为什么你我看到的不一样”。

为什么“使用者”模式下不能开启加速引擎？

因为加速引擎适合把结果固化下来复用，而使用者模式要求“不同登录人查到的结果可能不同”。

这两件事天然冲突：一旦结果需要按当前登录人动态变化，就不适合直接固化成统一的引擎结果。因此如果业务必须实时按用户裁剪数据，通常要在直连查询、连接权限、行权限建模等方向上设计，而不是指望加速引擎同时满足。

有独立权限表时，行权限应该怎么做？

这是客服和实施场景里非常高频的问题。常见做法有三类：

1. 建立 Fusion 数据集：把事实表和权限表一起建模，再把权限规则配在 Fusion 上
2. 把权限表作为模型从表：事实表关联权限表时，通常要注意关联方向与“始终关联”这类生效机制
3. 在建事实表时通过过滤条件引入权限表：适合某些不希望直接建模型、或多对多关系容易数据膨胀的情况

如果权限关系本身比较复杂，建议优先从“权限表和事实表的关系是一对一、一对多还是多对多”开始判断，而不是先选实现姿势。

为什么平台方已经把数据包授权给租户，租户普通用户还是看不到？

默认设计是严格权限控制：

• 平台方先把资源授权给“租户”
• 租户管理员再决定是否把它继续授权给租户内普通用户

所以“平台租户能看到”和“租户内所有用户都能看到”不是一回事。

如果你需要更宽松的默认行为，可以评估是否启用 PLATFORM_FOLDER_AUTH=read。但这类配置会改变整个平台/租户之间的默认可见边界，应先明确它是否符合你的治理策略，再执行配置并重启。

进一步阅读：

• 租户管理
• 权限管理