Security failure in Excel template.

[Guillaume Galtier]

Hi everybody, hereunder the problem I'm facing...

Users having not suffisant rights to access a part of data into a cube, can however access it through an excel template

End users are limited to their respectives plants. The security is ensured with }ElementSecurity on the dimension representing the plants.
My excel sheet is a simple synthesis table with all plants in lines and costs types in columns. All references to TM1 dimensions are hardcoded.

The security works fine using the TM1 interface, but fails using the excel template.

The problem seems coming from rules on my }CellSecurity cube, used to locked some crossings between dimensions elements.
If I delete these rules, the excel template works fine.

Any idea to resolve this ??

Thanks in advance

Guillaume

[Steve Vincent]

Its obviously the rules causing it, so 1st up i'd post those and see what we can see

[Guillaume Galtier]

ok Steve

Hereunder the rules causing the problem, from my }CellSecurity cube :

Code: Select all

# Lock FTE, FTEAVG, Rate FTE (M€) & Amount Key figures (FTE coming from cube RM_HR-Ref, Averages & Amounts are calculated)
[{'FTE', 'FTEAVG', 'Rate FTE (M€)', 'Amount (M€)'}]=S:'READ';

# Lock Actual
# If Line <> WF In Situ OH / NOH, Line <>Externalisation
['RM_REP_ValueType':'10']=S:
	IF(ELISANC('RM_HR_Line', 'WF_EXT_SC_INSITU', !RM_HR_Line) = 0 & ELISANC('RM_HR_Line', 'WF_EXTERN_OH', !RM_HR_Line) = 0,
		'READ',
		CONTINUE);

I add that these rules are not concerning the "plant" dimension on which i have defined the elements security. (}ElementSecurity).

Guillaume

[Steve Rowe]

Hi Guillaume,

My first guess would be that your rule ends with continue so the compilier is expecting more rules to apply to those cells and there are not any.

I'd suggest changing the continue to a stet, or finishing the rules with []=S: stet;
HTH

[Guillaume Galtier]

My first guess would be that your rule ends with continue so the compilier is expecting more rules to apply to those cells and there are not any.

Are you sure about this ? I thought that the compiler simply stopped when reaching the end of the rule, without expecting nothing else, even if the last statement treated was "CONTINUE"...

I'd suggest changing the continue to a stet, or finishing the rules with []=S: stet;

I have tested your suggestion, but the problem still remains...

Thanks
Guillaume

[Steve Rowe]

Going off topic now but...
I'm not sure, no but in a numeric cube at least if areas are left with defined as = continue, they display as ruled zero values, so I was thinking that this might casue strange behaviour in a string cube.
Cheers,

[Steve Vincent]

without the rules, are there string values in the cell security cube in some but not all cells you are trying to apply the rule to?

never used cell security but in rules i have used in element security i had issues with inconsistant results and it turned out to be feeders. If a cell already has data in it then you put rules on top, it acts like its fed and so works as you planned. If some didn't have data tho they would need feeding in order for the rule to work. I had massive performance issues doing it like this so ended up scrapping the rules and TI'd the values instead.

[paulsimon]

Guillame

I also avoid cell level security because of concerns over the performance overhead. However, according to the manual:

NOTE: For element-level security to apply to a cell, no security rights can be assigned to any TM1 security group for the cell. Cell-level security overrides element-level security, so cell-level security for the cell must be undefined.

So I suspect that your cube security rules which seem to give eg READ to a certain measure apply across all Plants and override the security that you have set on the elements in your Plant dimension. So even if a user has WRITE on a Plant element they will only get READ.

Quite why the security should differ in Excel vs Server Explorer seems odd. I am not clear as to whether Excel is still showing the Plant but then not allowing entry. It may be that the Excel implementation with regard to cell level security is good enough to prevent entry of data but not good enough to prevent display of the elements.

Anyway, it would seem that you cannot mix and match element and cell level security. If you use cell level security then you must do everything at the cell level. I guess you could still reference the dimension element security in the rules for your cell level security.

Personally I review whether you can replace cell level security with element level security.

Regards


Paul Simon