Security Strangness/Inconsistent Behavior

[George Regateiro]

I have come across a problem in one of our cubes and I am at a loss at the moment. We have an issue with users going into one cube (either through a template or through the cube viewer) and getting inconsistent security errors. I have seen where they write to a cell, refresh and attempt to write again and get the No Write Access error. It is hit or miss. Sometimes it happens consistently but other times it is a one off that they cannot write and then they can. There is nothing special in the templates that might confuse the DBRW and we are seeing the same issue in the cube viewer.

I have validated their security and all security is applied using physical values, no rules.

I am at a loss as to what to check next. My next step was to contact IBM, but I thought I would check here first.

We are on 9.5.2 FP1

[tomok]

No Write Access can also mean the are trying to enter into a consolidated cell or a cell that has a rule applied to it. This is likely your culprit.

[declanr]

You haven't got any "unusual" rules in the security cubes?

[George Regateiro]

Unfortunately that is a negative on both.

They were not entering to a consolidation I saw them do the entry. Also when we tried through the cube viewer the cell was white and still gave us the error.

We have no security rules everything was filled via a TI or hard coded.

I even had top open to make sure no one was doing an add user or something that would have affected the security and there was nothing going.

[declanr]

Now its interesting that you can see a white cell.

Other things that can sometimes cause a bit of a hissy fit are duplicate names of elements, although tm1 normally doesn't let you save a dim with duplicate names it will let you write a rule to populate an alias which causes duplicates... have you got any rule generated aliases or just any that could cause duplicate concern in general?

[qml]

Can you specify which of the following types of security do you have that would affect this cube?
a) cube security
b) dimension security
c) element security
d) cell security

Is there anything that affected users have in common? Do they belong to the same group(s)? Is there any pattern in it?

[George Regateiro]

Sorry for the delay in posting got swamped all of a sudden

As far as security we have

Cube, Dimension and element level security affecting that cube. All the security is hard coded into the cubes, we have no rule based secuirty.

As far as similarities

Dimension security is shared
Cube Security is based on their job role (about 12 different groups).
Element Security is by user

There is no rhyme or reason that I can tell since it will occur between sheet refreshes and then just work.

I have engaged IBM who is looking into the issue. Unfortunately I dont have any more then what I have said to go on. At the moment there is no concrete connections that I can make between the users. If IBM can find something I will certain post it and I am continuing to dig.

[tomok]

I just read your original post and the following jumped out at me:

that might confuse the DBRW

Could you perhaps have some DBRW references nested inside the DBRW you are trying to key into? This has been known to cause strange behavior. Make sure any nested TM1 formulas use DBR instead of DBRW.

[declanr]

Also when we tried through the cube viewer the cell was white and still gave us the error.

Sadly this suggests that its not a DBRW calc order issue this time but is instead something in the actual bones of the model.

[George Regateiro]

I figured it out. Not sure why I did not hit this before or in any other cube. There as a legacy rule that said IF(The version is part of the open version consolidation, COntinue, STET). In the rule tracer this was the only rule that the cells in question was hitting.

The behavior that I saw was

1) When the cell had write access tracing the rules would show me the rule above but the rule tracer would say that it was a simple element with the value that was in the cube
2) When the cell had no write access tracing the rules would show me the rule above and the rule tracer would say it was a Calculated element with the value that was in the cube

I am still going to pursue it with IBM but it is nice to know why. This was a rule we were phasing out as we have been optimizing our rules, but it seems strange that TM1 would be evaluating it differently even though in the end it should have been a simple value and not calculated.

[jstrygner]

Just got to this post.
I have a feeling you found a rule that was a cause for the behavior, but it is still a mistery, why the behavior is like this.

I am not assuming this is the reason, but is it possible, that this version dimension (or maybe any other involved in this cube) has a subset and that subset has the same name as one of the leaf elements in this dimension?

TM1 allows you to retrieve a rollup value of all elements that are in the subset by using DBRW to the subset name.
So when one of N elements has the same name as a subset TM1 could(?) sometimes treat DBRW like it would be pointing to N and sometimes to C element.