Skip to Main Content
IBM Data and AI Ideas Portal for Customers


This portal is to open public enhancement requests against products and services offered by the IBM Data & AI organization. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:


Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,


Post your ideas

Post ideas and requests to enhance a product or service. Take a look at ideas others have posted and upvote them if they matter to you,

  1. Post an idea

  2. Upvote ideas that matter most to you

  3. Get feedback from the IBM team to refine your idea


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

IBM Employees should enter Ideas at https://ideas.ibm.com


Status Is a defect
Workspace Planning Analytics
Created by Guest
Created on Aug 6, 2019

More clarity in Documentation on Hierarchy specific TI Functions that aren't Hierarchy specific

In the TM1 Reference Guide (which is still called that even though it is in the Planning Analytics Knowledge Centre) ...

 

The TI Function HierarchyElementSecurityPut takes a HierName parameter, however, it actually updates the }ElementSecurity_ cube, ie the Dimension level cube, rather than any new cube that has an additional Hierarchy dimension or an }ElementSecurity_: cube.

Similarly ElementAttrPutN/S take a HierName parameter. However, it actually updates the }ElementAttributes_ cube.

 

So in both cases the fact that the TI Function has a HierName parameter implies that it is possible to vary security or attributes by Hierarchy within a dimension but in practice this is not possible because the values are stored at the Dimension rather than the Dimension:Hierarchy level.

 

Ideally these functions should not have been created if they don't actually work. However, if this HierName parameter has actually been added for possible future use, then the Documentation should make it clear that the function is not currently Hierarchy Specific and the HierName parameter has no effect.

 

Personally, as far as Security goes, TM1 Security is already complex enough, and I don't see an immedaite need for it to be made Hierarchy Specific. I cannot see why I would ever want to give someone WRITE access to an Element in one Hierarchy and READ in another.

 

There is perhaps a greater case for Attributes, in particular Aliases being Hierarchy Specific. However, a simple work around for that would be to just create a different Alias for the Hierarchy, populate it appropriately and to then set that Alias in the Default Subset on the Hierarchy.

 

I have checked that the HierarchySubset functions are actually Hierarchy Specific.

 

Given this, is there really a need for the Hierarchy specific functions for Security and Attributes, which don't actually work.

 

Interested in Comments from other users as to whether they see a need for Security and/or Attributes to be Hierarchy Specific, and if so, why? 

 

Hierarchies are relatively new. IBM probably need to put more thought into what should and should not be hierarchy specific before creating functions that don't actually work as described.

Needed by Date Aug 6, 2019
  • Admin
    Stuart King
    Reply
    |
    Sep 14, 2020

    If documentation is unclear please open a defect APAR with IBM Support. The IBM Support team can assist with documentation corrections (they will escalate to documentation development).

    HierarchyElementSecurityPut is required for setting security of consolidated members that exist in hierarchies other than the same named hierarchy. The regular ElementSecurityPut function cannot be used to address consolidated members in hierarchies other than the default hierarchy of the dimension.

  • Guest
    Reply
    |
    Aug 28, 2019

    A separate ElementAttributes or ElementSecurity cube(s) is not needed because ... hierarchies!

    You ned to browse the alternate hierarchies of the dimension in the control cube and you will see that the calue is correctly stored against the C element in the correct hierarchy.

    Only for leaf elements are the attribute and security values shared and updating against one hierarchy also updates in any other hierarchy where the leaf is present.