Descendants subset in CAFE - not working with element security

[mvaspal]

Hi

Here is a simple dynamic subset:
{Descendants([Customers].[Total Customers]) }
Works as expected in Architect, Web. But if a user does not have access to the Total Customers element but to some of it descendants only, it does not return any rows in CAFE, not even the ones he has access to.

I trust your opinion here on this forum so I would be happy to hear: am I really going mad to think this is clearly a defect and should be managed as a defect and not as a feature of CAFE? Support answer as usual: maybe architect is wrong and CAFE is working as expected...so waiting for your votes guys

Thanks a lot!!

[lotsaram]

This should be raised as a bug.

[Steve Rowe]

Yes, this should be a bug, security should be applied to the results of the MDX statement.

[qml]

I agree with my esteemed colleagues that this should be a raised as a defect.

However, there could be some logic to it working like that based on the fact that CAFE originally comes from the Cognos side of things. Cognos BI has a different approach to hierarchical information than TM1. In order to be able to work with any member/element one has to have access to its ancestors too because they form part of the Member Unique Name (MUN) that Cognos uses. In effect if you have a dimension with one root member e.g. 'Total Customers' and all the elements being its descendants then hiding 'Total Customers' using TM1 element security will also remove access to all its descendants in Cognos. An unbroken chain of elements is needed starting from the root, otherwise Cognos will not see the elements below the break. IBM have introduced a workaround for this called 'filler members', but it's not very aesthetic. There are other tricks too, but clearly the usefulness and ease of use of traditional element security is greatly reduced and I'm not surprised there are defects in CAFE that might have their roots in this different philosophy. A philosophy that is well illustrated by the fact that Cognos BI sees the same TM1 dimension element that has two different parents as two different elements.

[mvaspal]

Hi

Thanks for all your feedback!

Qml, you are right, we arrived to the same conclusion that unfortunately CAFE behaves like BI in terms of element security. However, BI does not support TM1 subsets yet, but if CAFE does then I think it is fair to expect that it can handle TM1 subsets the same way as the "legacy" clients.

Anyway, I will let you know if we have it accepted as a defect.

[Steve Rowe]

If this is not a bug, but a change in the way the TM1 security model works, as per Kamil's post, then moving to café from perspectives will likely mean re-writing the security model for most complex apps.

That's going to leave a lot of people between a rock and a hard place since at some point in the future we are all going to end up on café if we want to stay on the current release...

Worrying....

[mvaspal]

Hi
It has been accepted as a defect.

In the meantime you can use TM1DrillDownMember which does the similar thing and works correctly with element sec in CAFE

[mvaspal]

update: 6 weeks after accepted as a defect by Support it was rejected as a defect by Development, so this is an expected behavior and won't change in CAFE

[Steve Rowe]

Can you see the data associated with the elements that you shouldn't be able to see?

Did they give any justification for it not being a bug?

[lotsaram]

I think this needs more persistence. To my mind this is clearly a bug.

[mvaspal]

I agree with you guys but I gave up discussing anything with IBM Support