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,
Post an idea
Upvote ideas that matter most to you
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.
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.
Do not place IBM confidential, company confidential, or personal information into any field.