Behaviour of expanding and collapsing a consolidated member in the Pafe Cube Viewer / Set Editor / Exploration view

Suggest and discuss enhancements for TM1
Post Reply
User avatar
Steve Rowe
Site Admin
Posts: 2297
Joined: Wed May 14, 2008 4:25 pm
OLAP Product: TM1
Version: TM1 v6,v7,v8,v9,v10,v11+PAW
Excel Version: Nearly all of them

Behaviour of expanding and collapsing a consolidated member in the Pafe Cube Viewer / Set Editor / Exploration view

Post by Steve Rowe »

Hi, Please vote for my RFE, this has already been through a support call -> APAR-> OM reject cycle lasting 11 months so I'm keen to keep the profile of this high.

Details as follows.

Pressing the plus next to a parent should always show me all the children of a parent irrespective of the activity has taken place previously.

Currently the right hand side of the set editor, the cube viewer and exploration views do not behave in this manner.

For example if I start with a cube viewer in Pafe
pic1.png (24.16 KiB) Viewed 25485 times

And I hide the East Region off the right click menu.
pic2.png (42.13 KiB) Viewed 25485 times

Then the act of hiding the East Region is retained through subsequent activity.

Say I decided I want to unhide East Region as I mis-clicked, then when I click the “-“ next total company and then plus to refresh the child list the hide East Region action is retained.
pic3.png (30.36 KiB) Viewed 25485 times

If I slice this view to an exploration then I see the incorrect behaviour, -/+ does not restore the child list.

This means that it is fairly straight forward to generate incorrect views and slices that do not reconcile (i.e. children do not sum to parents) in a non-obvious manner. The application is too easy to break.
Using the hide button in the set editor gives similar behaviour, here you can see the MDX “going wrong”.

Step 1 In the right hand side of the set editor we start with an expanded list of Total Company
This is generated by the MDX
DRILLDOWNMEMBER({[organization].[organization].[Total Company]} , {[organization].[organization].[Total Company]} , RECURSIVE)

Step 2 If I hide the East Region I get the following MDX with except being used to remove the element (East Region is the alias for element 100)
EXCEPT(DRILLDOWNMEMBER({[organization].[organization].[Total Company]} , {[organization].[organization].[Total Company]} , RECURSIVE) , {[organization].[organization].[100]})

From this point the MDX recording goes wrong (in my opinion).
Step 3 If I rollup the Total Company element I get the following MDX, you can see that the exclusion of East Region has been retained in the MDX, even though MDX itself is just returning Total Company
DRILLUPMEMBER(EXCEPT(DRILLDOWNMEMBER({[organization].[organization].[Total Company]} , {[organization].[organization].[Total Company]} , RECURSIVE) , {[organization].[organization].[100]}) , {[organization].[organization].[Total Company]})

Step 4 Expanding Total Company should get me to the original MDX in step 1 but instead gets me to the MDX from step 2
EXCEPT(DRILLDOWNMEMBER({[organization].[organization].[Total Company]} , {[organization].[organization].[Total Company]} , RECURSIVE) , {[organization].[organization].[100]})

What is interesting to note here is that in step 3 the MDX recorder is not blindly recording my steps but applying some flawed (?) logic and rolling back to step 3. If it had continued to blindly record my steps then the missing child problem would not occur (I think).

The MDX recorded in the set editor is not behaving in a sensible logical fashion. Retention of past activity is generating defective sets in the front end.
Technical Director
Post Reply