IBM Data and AI Ideas Portal for Customers

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:

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

Help IBM prioritize your ideas and requests

The IBM team may need your help to refine the ideas so they may ask for more information or feedback. The product management team will then decide if they can begin working on your idea. If they can start during the next development cycle, they will put the idea on the priority list. Each team at IBM works on a different schedule, where some ideas can be implemented right away, others may be placed on a different schedule.

Receive notification on the decision

Some ideas can be implemented at IBM, while others may not fit within the development plans for the product. In either case, the team will let you know as soon as possible. In some cases, we may be able to find alternatives for ideas which cannot be implemented in a reasonable time.

Additional Information

To view our roadmaps:

Reminder: This is not the place to submit defects or support needs, please use normal support channel for these cases

IBM Employees:

The correct URL for entering your ideas is:

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
    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
    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.