Contributor overwriting security - okay, but ...

[cbeycwright]

I've been tangling with Contributor and I feel like I'm missing something. Part of my security model is based on cost center, so I have some rules in }ElementSecurity_CostCenter which help keep my clients & groups straight. For the same reason that I chose to base overall system security on cost center, I am also wanting to base Contributor's approval on cost center: it's maintained, it links back to functional areas in the system, etc. However, Contributor flatly states that it will take control of the security for the dimension you include your approval subsets in and, unfortunately, part of taking control means wiping out the rules. In other words, Contributor undoes my security model.

This really blows because cost center is the only thing that makes sense for me to run my approvals through.

I doubt I'm the only person to have this issue. Just curious if I'm missing something or if this is an issue other folks have run into and figured out a workaround for.

Thanks for reading.

[Martin Ryan]

Haven't tried it, so I've no idea if it'll work, but you might be able to stick rules in the control cube "}CellSecurity_}tp_application_permission}{ff9aae85-2d75-48a9-887f-6f0330c072f1}" (yours will have a slightly different ID of course) that replicate what occurs in the other cube.

Martin

[cbeycwright]

Thanks for the tip. I'll check that out. Something else I was considering is cloning my cost center dimension and ruling the element security cube for the clone to support system groups. Meanwhile, the real cost center dimension could be manhandled by Contributor freely. The downside is maintenance of the clone, which could be done relatively painlessly by a process. The upside is that I would get to use the dimension that I want to use - cost center - for Contributor.

Not sure if that's the route I'll take, but I'll let you know what I end up doing. Thanks for the advice.

[soprano96]

Haven't tried it, so I've no idea if it'll work, but you might be able to stick rules in the control cube "}CellSecurity_}tp_application_permission}{ff9aae85-2d75-48a9-887f-6f0330c072f1}" (yours will have a slightly different ID of course) that replicate what occurs in the other cube.

Martin

Martin -

Is there ever a scenario where that cube will be overwritten, or is it the case that once you've created the Contributor application, that Cell Security cube is there for good? I don't want to get into the situation where Contributor overwrites my security rules in this situation the way it was overwriting our security rules in that cost center dimension.

Paul

[Martin Ryan]

Not sure Paul, I've never used Contributor in anger, and have not even tried the rule suggestion I made above. However I would expect that once the application has been created that the control cube is there for good and won't change.

If I had a need to do this and the rules were getting overwritten every so often (not constantly) I would write the rules in a text file and use turbo integrator to reload them as required.

Martin

[cbeycwright]

Follow-up on this: I've spoken with IBM about this issue - children not able to have multiple parents in approval hierarchy/dimension - as well as another pesky issue I'm dealing with. The official response on the first issue is that Contributor doesn't support multiple hierarchies in the approval dimension, which is not a surprise. However, they have had a rash of complaints, unofficially, about this behavior and are working to change this. They did offer me some MDX to try - it didn't work for me. Here's what I got from IBM support:

In order to use a dimension that has multiple hierarchies, you need to use an MDX statement:

{[<dim name>].[<top node>], Filter([Cost Centers for Planning].members], IsAncestor([<dim name>].[<top node>], [<dim name>].currentmember)) }

Use this dynamic subset just for the approval hierarchy, there is NO need to use it in the views for TM1 Contributor and I would recommend against using Dynamic Subsets/UDCs also due to there heavy handed locking characteristic.

[atxchillin]

I ran into a similar problem. I have multiple contributor applications against the same TM1 model. I need to manage security against the workflow dimension from application A for groups in application B. Contributor was overwriting the rule.

I edited the process }Tp_Application_deploy (which runs everytime you save contributor security) and put a line in to load the rule from file. Everytime they save contributor security, contributor overwrites my rule, but then the process moves the rule back in. I've only been using it for an hour but will post back if it causes any issue.