<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>But the overall result of what I'm seeing is still confusing/incosistent:</div><div><br></div><div>So the 2 roles:</div><div>"No HR Cube"&nbsp;</div><div>- Schema grant "all"</div><div>- Cube grant "HR" "none"</div><div><br></div><div>California manager</div><div>- Schema grant none</div><div>&nbsp; Cube grant Sales all</div><div>&nbsp; Hierarchy grant store</div><div>&nbsp;<span class="Apple-tab-span" style="white-space:pre">        </span>- topLevel="[Store].[Store Country]", <span class="Apple-tab-span" style="white-space:pre">        </span></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>- member grant "Los Angeles" NONE</div><div><br></div><div>1) SchemaGrant : all and none =&gt; "all" is applied</div><div>2) Cube grant: HR none + "all" from schema are applied =&gt; between &nbsp;"just showing Sales" and "all but HR" we see "all but HR" since both roles dont see this cube on its own</div><div>3) Hierarchy grant</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>topLevel = Store Country =&gt; we see this as toplevel, although the other role would see all levels, not consistent with your described approach</div><div>4) MemberGrant "Los Angeles" NONE =&gt; we see this member, because "No HR Cube" role can see this member, consistent with your described approach again</div><div><br></div><div>So especially 3 is at least "wrong" from my POV.</div><div><br></div><div>If we really "union" all =&gt; least restrictive, it is quite hard to define fine-grained data access without having a lot of roles that all include every detail of the cube (each role would have to include all grant objects).</div><div>Is the only way to have this a programmatic role that knows about all that? (Well I guess a DSP would work too)</div><div><br></div><div>I think it should either a) use the most permissive b) the most restrictive c) overrule implicit with explicit rules</div><div><br></div><div>The people I talked to about this today had a similar views. No matter which one of the above it should do.. it should at least be consistent.</div><div><br></div><div>I guess I can always create my own role that delivers what I need, but I think it makes sense to discuss the current implementation first.</div><div><br></div><div>-Paul</div><div><br></div><div><br></div><div><br></div><div><font class="Apple-style-span" face="Menlo"><span class="Apple-style-span" style="font-size: 11px; "><br></span></font></div><div><span class="Apple-style-span" style="color: rgb(168, 0, 192); font-family: Menlo; font-size: 11px; "><br></span></div><div><br></div><div><div>On Nov 26, 2012, at 6:03 PM, Julian Hyde wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>That's mostly right.<br><br>The philosophy is a bit different than you describe. It's irrelevant whether a role has explicit or implicit access to a particular object (cube, dimension, etc.) If role A can see X, and role B cannot, then the union role can see it. For example, even if A explicitly cannot see cube X (because of a &lt;CubeGrant name='X' access='none'/&gt;) and B implicitly can see cube X (because of a &lt;SchemaGrant access='all'/&gt;), the result is still that the A-union-B role can see cube X.<br><br>Julian<br><br><br>On Nov 26, 2012, at 3:47 AM, Paul Stoellberger &lt;<a href="mailto:p.stoellberger@gmail.com">p.stoellberger@gmail.com</a>&gt; wrote:<br><br><blockquote type="cite">So I was just playing with roles and I configured my foodmart to use both roles "No HR Cube" and "California Manager" for my dummy user.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Now the result is rather interesting:<br></blockquote><blockquote type="cite">1) I don't see a HR cube, but all other (although california manager has only access to sales), so the union works as i expect it<br></blockquote><blockquote type="cite">2) the customer / store hierarchy in Sales are restricted (top / bottom level) =&gt; see <a href="http://jira.pentaho.com/browse/MONDRIAN-1168">http://jira.pentaho.com/browse/MONDRIAN-1168</a><br></blockquote><blockquote type="cite">3) i can see the city &nbsp;"Los Angeles" in the results, althoug I was expecting not to see them.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">If the level restriction (access none) worked, so should the member access.<br></blockquote><blockquote type="cite">While there is now a Math.min() for levels, its a max() for members etc.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">The "No HR Cube" doesn't set explicit access restriction on the customer / store hierarchy, so the one from california manager should overrule it.<br></blockquote><blockquote type="cite">If both had access set explicitly on that hierarchy / member it should use max() of both, but not if only 1 sets it.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Before I propose any changes to RoleUnionImpl I wanted to know if you agree with that?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">-Paul<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">Mondrian mailing list<br></blockquote><blockquote type="cite"><a href="mailto:Mondrian@pentaho.org">Mondrian@pentaho.org</a><br></blockquote><blockquote type="cite"><a href="http://lists.pentaho.org/mailman/listinfo/mondrian">http://lists.pentaho.org/mailman/listinfo/mondrian</a><br></blockquote><br>_______________________________________________<br>Mondrian mailing list<br><a href="mailto:Mondrian@pentaho.org">Mondrian@pentaho.org</a><br>http://lists.pentaho.org/mailman/listinfo/mondrian<br></div></blockquote></div><br></body></html>