[Mondrian] UnionRole and explicit / implicit rules

Paul Stoellberger p.stoellberger at gmail.com
Mon Nov 26 12:24:24 EST 2012

But the overall result of what I'm seeing is still confusing/incosistent:

So the 2 roles:
"No HR Cube" 
- Schema grant "all"
- Cube grant "HR" "none"

California manager
- Schema grant none
  Cube grant Sales all
  Hierarchy grant store
 	- topLevel="[Store].[Store Country]", 	
	- member grant "Los Angeles" NONE

1) SchemaGrant : all and none => "all" is applied
2) Cube grant: HR none + "all" from schema are applied => between  "just showing Sales" and "all but HR" we see "all but HR" since both roles dont see this cube on its own
3) Hierarchy grant
	topLevel = Store Country => we see this as toplevel, although the other role would see all levels, not consistent with your described approach
4) MemberGrant "Los Angeles" NONE => we see this member, because "No HR Cube" role can see this member, consistent with your described approach again

So especially 3 is at least "wrong" from my POV.

If we really "union" all => 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).
Is the only way to have this a programmatic role that knows about all that? (Well I guess a DSP would work too)

I think it should either a) use the most permissive b) the most restrictive c) overrule implicit with explicit rules

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.

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.


On Nov 26, 2012, at 6:03 PM, Julian Hyde wrote:

> That's mostly right.
> 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 <CubeGrant name='X' access='none'/>) and B implicitly can see cube X (because of a <SchemaGrant access='all'/>), the result is still that the A-union-B role can see cube X.
> Julian
> On Nov 26, 2012, at 3:47 AM, Paul Stoellberger <p.stoellberger at gmail.com> wrote:
>> 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.
>> Now the result is rather interesting:
>> 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
>> 2) the customer / store hierarchy in Sales are restricted (top / bottom level) => see http://jira.pentaho.com/browse/MONDRIAN-1168
>> 3) i can see the city  "Los Angeles" in the results, althoug I was expecting not to see them.
>> If the level restriction (access none) worked, so should the member access.
>> While there is now a Math.min() for levels, its a max() for members etc.
>> The "No HR Cube" doesn't set explicit access restriction on the customer / store hierarchy, so the one from california manager should overrule it.
>> If both had access set explicitly on that hierarchy / member it should use max() of both, but not if only 1 sets it.
>> Before I propose any changes to RoleUnionImpl I wanted to know if you agree with that?
>> -Paul
>> _______________________________________________
>> Mondrian mailing list
>> Mondrian at pentaho.org
>> http://lists.pentaho.org/mailman/listinfo/mondrian
> _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20121126/2f8fb2a6/attachment.html 

More information about the Mondrian mailing list