[Mondrian] XMLA Security

Matt Campbell mkambol at gmail.com
Thu Apr 5 08:52:02 EDT 2007


In AS2K you can set whether to use visual totals in the Role definition.  It
defaults to show the full aggregate total, but you can change that on a
dimension by dimension (and level by level) basis.

On 4/5/07, Julian Hyde <julianhyde at speakeasy.net> wrote:
>
>  Can you also contribute a unit test, against the foodmart schema? Code
> without a unit test is like a really cool Xmas present with no batteries
> included! See mondrian.test.AccessControlTest and mondrian.test.SchemaTestfor some examples.
>
> I don't agree that members should be the total of only their *visible *children.
> For example, if Fred has access to only [USA].[CA].[San Francisco] and
> [USA].[CA].[Oakland], I think the total for [USA].[CA] should include all
> cities in California.
>
> I don't deny that there are cases where you would only want to see the
> total of the accessible cities. But in my opinion it shouldn't be the
> default behavior. I think there is some way to write a calculated member for
> that - I would be open to extending the language to make that easier to
> achieve. Anyone know what MSAS does here?
>
> Julian
>
>  ------------------------------
> *From:* mondrian-bounces at pentaho.org [mailto:mondrian-bounces at pentaho.org]
> *On Behalf Of *Pedro Casals
> *Sent:* Wednesday, April 04, 2007 4:04 AM
> *To:* Mondrian developer mailing list
> *Subject:* Re: [Mondrian] XMLA Security
>
>  Thanks to your hint I realized that code changes were small. Since I have
> no access to CVS, I post here the changed classes. All changes are marked
> with this comment: //PCF : role
> Besides, I attach a default callback implementation and the needed
> modification in web.xml.
> I also attach the security role definition, that covers most of the
> situations:
> - Grant only some measures
> - Deny a hole dimension.
> - Deny part of an hierarchy, both in levels and members
>
> Pending:
> JPivot is not placing the role in the HTTP header. I will ask to Andreas
> which is his preferred approach, and my proposed solution.
>
> Known bug at this moment:
> - Security role definition is order dependant, more than specified in doc.
> For example: in my role definition, if the definition of [Estructura
> Comercial] is placed before Dimension definition, the latter is not taken
> into account!
> - look at XMLA Security bug.xls attached file. If a member of a level of
> an hierarchy is denied, the member is computed for the totals of the
> ancestors (wich is wrong), but is not computed on its own level (wich is
> correct).
>
> Pedro
>
> ----- Mensaje original ----
> De: Julian Hyde <julianhyde at speakeasy.net>
> Para: Mondrian developer mailing list <mondrian at pentaho.org>
> Enviado: martes, 3 de abril, 2007 18:53:55
> Asunto: RE: [Mondrian] XMLA Security
>
>
>
>  **
> The problem with this security role is that when I try to retrieve all the
> children from [Estructura Comercial].[Toda la Estructura].[01] I get none,
> because the code navigates tries to solve the name one part at a time, but
> we do not have access to [Estructura Comercial].[Toda la Estructura].
>
> Is it that the role definition is wrong or should I adjust the code (which
> is really complicated!!!!)
>
>
> The code which looks up the member being granted should definitely do so
> in a non-access-controlled context. By all means adjust the code (and be
> sure to add a unit test for the bug). Maybe use the global schema reader?
>
> Julian
> _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian
>
>
> ------------------------------
>
> LLama Gratis a cualquier PC del Mundo.
> Llamadas a fijos y móviles desde 1 céntimo por minuto.
> http://es.voice.yahoo.com<http://us.rd.yahoo.com/mail/es/tagline/messenger/*http://es.voice.yahoo.com/>
>
>
> _______________________________________________
> 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/20070405/db144a2b/attachment.html 


More information about the Mondrian mailing list