一个用户看到PowerBI报表需要两个权限，一个是 访问权限 ，另一个是 行级别安全性 (数据权限管理)，即常说的Row-level security ( RLS )，两个权限的优先级是访问权限>RLS，需要先获得访问权限进入报表才能谈RLS。
开发者的角度是先在报表上设置好RLS，赋予用户数据权限，然后发布报表再去分享给用户（用户获得访问权限）。
先看模型，如下：
经典的星型模型，通常权限控制的做法是控制一个用户能看到的Place与Product的子集大小（什么地区什么产品），明细数FACT表就进而被控制了。
1.导入权限表
地区权限表
产品权限表
不用连接任何关系线
2.管理角色-新建角色
新建唯一一个角色【通用权限组】：
设置这个角色的Product维表过滤规则
设置这个角色的Place维表过滤规则
[产品] = LOOKUPVALUE ( '用户产品权限表'[产品], '用户产品权限表'[用户email], USERPRINCIPALNAME (), '用户产品权限表'[产品], 'product维表'[产品] ) [城市] = LOOKUPVALUE ( '用户地区权限表'[地区], '用户地区权限表'[用户email], USERPRINCIPALNAME (), '用户地区权限表'[地区], 'Place维表'[城市] )
解读第二个DAX：
[城市] 是维表【城市】字段的每一个值，LOOKUPVALUE同样返回一个值，两相对比，返回真假，然后筛选的 Place维表【城市】字段，实际上就是将真/假传递回维表，真的行数要，假的剔除 。
LOOKUPVALUE函数的作用：
USERPRINCIPALNAME ( ) 返回登录PowerBI网页端的用户名，将这个用户名以及'Place维表'[城市]作为查找值去查找 '用户地区权限表'[用户email] 以及 用户地区权限表'[地区]字段 ，最后返回这个用户所对应的地区（城市）。
3.验证权限
验证Place权限
对比两张权限表可知全设置是正确的，sami.law@aoct.com只能看到深圳地区-华为以及oppo的数据
现在详细描述一个这权限控制的流程：
权限表限定了用户所属的地区和产品， USERPRINCIPALNAME( ) 函数在用户登录时生效并返回用户名， LOOKUPVALUE( ) 函数通过用户名在权限表查找这个用户所拥有的地区和产品，最后在两张维表分别筛选出这个用户所拥有的地区和产品，维表通过关系传递到事实表。所以这种权限表配置法只需要维护权限表，只需一个角色即可，这个角色只充当一个桥的作用，这种权限控制方案较为灵活。
4.分配用户到角色
发布报表到网页端PowerBI server后
数据集页面->安全性->添加成员
完成后，用户还是只有读取报表数据权限，没有访问报表的权限
5.分享报表
分享完，用户（登录的账号 必须是 Power BI Pro ）通过email或者其他途径得到链接，点击进去就能看到报表了；
报表数据正确的前提是这个用户在两张权限表里，权限表通常需要手工维护 。
题外话：
数据集 -> 管理权限 ，进入权限页面可管理所有人的权限
6.开发者报表页面验证数据
因为开发者与用户的账号是不一样的，当用户报告数据不对劲时，开发者一般无法获得用户的账号去测试的（大概就只能看到用户发邮件过来的截图），可能用户筛选错了，可能误点了，总之有无数种情况。
首先两张权限表各复制一份，然后去连接维表
在筛选窗格，所有页面->放置这两张新加的权限表的email字段
点击用户的email即可验证用户反馈的问题（截图），此方法只能验证用户误点等情况，假如真是RLS设置错误还是需要下载报表仔细检查。
7.后记，预先写好权限度量值的做法
城市权限 = VAR city_access= CALCULATETABLE( VALUES('权限表'[城市权限]), '权限表'[账号]=USERNAME() ) RETURN SELECTEDVALUE('客户表'[客户城市]) IN city_access
标签：权限,配置
