TM1 Forum

<climbing out of the rock I have been under>

<rolling up sleeves, pulling out wren.... I mean spanner and getting ready to get my hands dirty>
I am looking to revamp my current cumbersome security model, and as part of that I am trying to evaluate the impact on performance for having security derived by rules.

I have successfully written the first part of the rule I want. The goal was to restrict write access to years that are current orbeing budgeted based on a year dimensions attributes. See Below.

My problem is that when I suppress zeros nothing is there, meaning a feeder issue. However, this confuses me. I thought that feeders were only required is skipcheck was on. I could be wrong, but that was my thought.

Since I am probably wrong, then I still have a concern. I know my feeder should come from my year attribute cube, but what is the best wat to feed from that cube?

I would expect the feeder to look like:
Is there a way t make the !}Groups dynamic so I do not need to write a rule for every security group or maintain the rule when new groups are added?

Thanks in advance!

Hi Eric,

System cubes work a bit different from normal cubes. I.e. feeders aso often don't work / at least not in the same way.

That being said why would you need a feeder on this? You are setting strings so it's not as if you are ever going to look at a consolidated value in there.

My suggestion: forget about writing a feeder for this, and keep skipcheck in.

Jeroen

I agree with Jeroen here. After running into lots of headaches, I never use SKIPCHECK with control cubes of any kind. In general, they're small enough that the impact to performance is low. Zero suppress sometimes doesn't work correctly with string cells and consolidations, doubly so on control cells which operate like sting cells but are listed as N and C cells in the dimension editor.

Matt

P.S. And, if you do use replication (don't!), string consolidations in control cubes do not replicate, at least in 9.1.4. (PMR 79534,019,866)

That being said why would you need a feeder on this? - Jeroen

Originally I did not think I needed one, but it was not working so I thought I missed something.

keep skipcheck in - Jeron

I never use SKIPCHECK with control cubes - mattgoff

I will keep it like I originally thought. I agree the cube is 2 dimensional and small, performance impact should almost me nothing.

Zero suppress sometimes doesn't work correctly with string cells and consolidations, doubly so on control cells which operate like sting cells - mattgoff

This is probalby what is messing me up. I will keep the rule, reboot the server, and see what happens.


Thanks!

Still not working..... I wonder is the Continue statement is messing things up? Since the control cubes feeders are different, maybe this is impacting it..... I will try nesting if statements instead of using the continue functionality and keep you all posted.

Eric wrote:
Still not working..... I wonder is the Continue statement is messing things up? Since the control cubes feeders are different, maybe this is impacting it..... I will try nesting if statements instead of using the continue functionality and keep you all posted.

What exactly is not working? At first glance your rule should work. (and whether you keep skipcheck in or out is not going to have a significant impact, agree on that)

Sorry for not being specific.

Rules are working, but security is not being restricted to coincide with the rule.

I did not notice it in the post so I will ask:

Are you doing a Security Refresh after you change the rules? If not you will see the changes in the Control Cube, but they will not be reflected in the actual security.

Good question, and you are right I did not mention it, but I am preforming the security refresh.

What about cube level security? It's possible you might have an empty cell level security cube that is interfering with things.

How are you testing? Does it still fail on a brand new cube?
Cheers

Had this myself previously Eric. It appeared that by trying to save it once with FEEDSTRINGS on the security cube, it essentially buggered the cube fundamentally when we took it out and although it looked like it should work (as much as the control cubes look right when supressing zeroes) it was fundamentally flawed. Took server down, deleted the security cube, dims, etc and restarted server then saved rules back in minus feedstrings and worked fine. Later tested again by saving with feedstrings (model stopped working) then removing feedstring statement again and resaved it and failed to work from that point on. Tried a third time a few months later and showed same consistent response.

So essentially my findings suggested to me that anyone saving a feedstrings into a control cube got their hands chopped off.

Would suggest bringing server down, killing all the security cube components, bring it up so it generates the cube automatically and save rules without feedstrings and check if it works.

Fingers crossed

Gary,

Thanks I will try that later in the week and let you know what happens, but it sounds like you figured it out.

Feedstrings is probably essential to get right if you ever have any decent sized cube with cell security. But any 2D security cube is going to be dense by definition so there is nothing to gain from Skipcheck or Feedstrings.

Feedstrings is often a little flaky and doesn't quite work as it should (in terms of not actually feeding the strings) but I never heard of Feedstings corrupting a security cube before.

Just to qualify lotsaram's statement slightly, IMO

Feedstrings is needed to get the display in the cubeviewer / zero suppression working but shouldn't be required at all to get the security working and shouldn't impact the perfomance of the security. ( In fact having Feedstrings when you don't need them will slow server starts down, especially with large numbers of groups)

Could be wrong of course so feel free to say so!
Cheers

I should have been more specific. If cell security cubes are being used with PrivilegeGenerationOptimization then only fed cells in security cubes will be processed. This can dramatically shorten server load time, but it does mean all values must be correctly fed (if rule populated).

Eric wrote:
I would expect the feeder to look like:

Code: Select all

['Status']=>DB('}ElementSecurity_Year',!Year,!}Groups)

Is there a way t make the !}Groups dynamic so I do not need to write a rule for every security group or maintain the rule when new groups are added?

Thanks in advance!

Is there answer for Eric's question on a way to feed all groups when there is no group rollup?

I am stumbling along trying to get PrivilegeGenerationOptimization working on a instance with 25 miunte security refreshes due to CellLevell security.

Maybe I'll try making a group of groups. I'm using CAM security.

Thanks,

-- John

I just came across this issue with a new company. They have PrivilegeGenerationOptimization turned on. I added rules to an element security cube, and the security did not take. I added feeders from clients group to the element security cube, and that got the security working. I fed from clients groups because I didn't have a consolidation for groups. I confirmed that it would be ok to add a consolidation, but I also got permission to turn off the PrivelegeGenerationOptimization flag. We had only a couple seconds change to server start time (less than 1%), and that also fixed the issue.