Cell level security

[dan.kelleher]

Hello,

Having a bit of an issue with rule-based security that hopefully someone can answer.

I have a security cube that needs to be populated based on whether a project has been signed off for a particular period, for argument's sake my cubes are simplified as follows:

cbSignoff: dimYear, dimPeriod, dimProject

cbCellSecurity: }Groups, dimYear, dimPeriod, dimProject, dimOther1, ... , dimOthern

How do I create a rule in the security cube that assigns 'READ' to all the cells where the value is 1 in the cbSignoff cube?

The problem I am having is that there are dimensions that exist in the in the security cube, but not in the sign off cube. How do I reference all elements in the dimension in the security cube where there is not a matching dimension in the signoff cube?

Any help would be greatly appreciated.

Thanks,

Dan

[John Hammond]

Having had a chat on this with Dan I hope this states the problem in the simplest possible way

We have a source cube of security info with one dimension and a target cube with two dimensions where a string is to be set on the basis of the first dimension.

sourceCube dim1
targetCube dim1, dim2

calc is:

[] = S:if(DB('sourceCube',!dim1) = 1, 'read', 'write') ;

Feeder is:

[] => DB('targetCube',!dim1,???????????????????????) ;

The problem is that we want one value in the source to feed many values in the target. If dim1='x' has a non zero value in sourcecube, we want feeder flags set in the targetcube for the area in the target cube ie we need a DB equivalent of targetCube[dim1:x] in square bracket notation.

What goes in place of ?????????? to represent a wildcard in a DB statement since you are required to provide all dimensions of the cube in a DB statement.

Hopefully someone out there has the answer...

Thanks.

[John Hammond]

IIRC the answer may be

Feeder is:

[] => DB('targetCube',!dim1,!) ;

where ! represents the whole dimension. Can anyone confirm this please?

[John Hammond]

I can confirm that this does not work since the advanced rules editor wont even allow it.

[David Usherwood]

You're in luck.
Since you are creating strings, feeders are irrelevant. Don't bother writing one. You'll need to cater for the higher level cells of course.
Note also that the advanced rules editor is buggy - just because it won't accept an entry doesn't mean it is invalid. But in this case, it's not telling porkies.

[Steve Rowe]

Just to close the circle on this one.

[] => DB('targetCube',!dim1,'A consolidation containing all the elements in the dimension') ;

But also to agree with David that you don't need to feed the cube since it is strings and for internal use you don't need to (and probably should not since it will have a performance impact, mainly slow down server starts).
1. Strings mean that there are no consolidations and hence no feeders required to make the consolidation work quickly.
2. Internal system use means that there is no requirement for viewing with zero suppression on and so no need for feeders.

HTH

[John Hammond]

Thanks Steve and Dave for giving me the solution...

Forgot that a consolidation works as shorthand notation for all levels beneath it as far as feeders go...

Couple of things I found out while trying to solve this.

1. Brace subset notation as used in MDX works with [] area notation but not DB. ie [{'a','b'}] works but not DB('mycube', {'a','b'}).
2. You cant extend MDX notation beyond the basic subset notation eg things like TM1SUBSETALL expressions seem to be impossible in [] notation. I didn't try the more standard MDX stuff like children so don't know if that will work.
3. Had always assumed that if any element in an intersection was type string you had to store a string in the cube but its actually only when the last element is a string element. (Hopefully that's somewhere in the manual like all the hidden TM1 info...)
4. I guess you only have to use N:/C: notation when an area refers to both consolidation and non consolidations. Presumably if you only have Consols in your area or vice versa it is not needed.

I suppose not putting this stuff in the manual really makes you appreciate this forum!