一、它控制什么

ReadSourceData 挂在立方体权限（CubePermission）下，官方描述分两层：一方面，它决定立方体权限范围内包含的层级，其唯一名称如何生成；另一方面，两个取值直接对应"是否允许访问计算第 0 遍（calculation pass 0）上的数据"。

把这两句合起来读就通了：要生成唯一、可读的成员名称，就需要读源数据；不允许读源数据，名称生成自然受限。

二、两个取值

默认是 None。也就是说，不做任何配置时，这类访问是被禁止的——这是"最小权限"思路的体现：先关着，需要再开。

三、"计算第 0 遍"是什么，为什么和权限有关

多维模型计算指标时是分遍进行的：第 0 遍是基础聚合结果，之后各遍在其上做计算成员、作用域分配等运算。权限限制通常作用在最终可见结果上，而第 0 遍的数据更"原始"。

这就带来一个现实取舍：

• 不允许访问第 0 遍：权限边界更严，但某些依赖源数据的能力（如成员唯一名称生成）会受影响；
• 允许访问：功能更完整，但等于向该角色开放了更底层的数据视图。

所以这不是"开了更好"的开关，而是一个安全与功能之间的权衡点。

四、典型症状与判断

五、怎么处理得稳妥

1. 先确认需求：是"要能查到数"，还是"要能正确显示成员名称"？两者不是同一件事；
2. 按角色区分：对外部使用者保持 None，对内部建模与运维角色按需开启；
3. 改完做验证：换用该角色的账号实际登录查一次，别只看配置界面显示已保存；
4. 写进文档：这个开关默认关闭，且症状隐蔽，不记录的话下一个人还要再查一遍。

一句话总结：这是一个典型的"默认安全、按需放开"的配置。它的坑不在于难配，而在于症状看起来跟权限毫无关系——记住这条关联，能省下半天排查时间。