restrict write access for few months

[SBK88]

Hey guyzzz,

Need ur help.
I have to restrict write access for tyhe users for (say ) Jan Feb and Mar.
As there are lot many groups in our model so this I need to implement through Rules.
what I have done, right clk on cube ABCD >> Security >> Create cell security cube.
In }CellSecurity_ABCD i have created a rule file and have written

[{'Jan','Feb','Mar'}] = S:'READ';

values in }CellSecurity_ABCD cube for the corresponding months got updated, but I still found that the cube ABCD is still updatable for the corresponding months( Jan, Feb Mar) ie. cells are not grey, they are still white and I can enter the data in those cells.

Is there anything that I have missed?

Need ur help.

[declanr]

First of all I would recommend making the rule dynamic by doing a look up to which months are "actualised" etc.

Second of all when you say "you can enter"... I am assuming you are an admin at which point security doesn't apply to you.
However if you did check after logging in as a standard user - remember that rule security doesn't apply automatically and needs a security refresh instead which can be done via TI process or right clicking the server => security => refresh security.

[qml]

remember that rule security doesn't apply automatically and needs a security refresh instead which can be done via TI process or right clicking the server => security => refresh security.

Rules applied to cell security cubes, unlike rules in element/cube/dimension/process security cubes, do not require a security refresh to kick in.

[paulsimon]

Hi

You generally only need CellSecurity when your security requirements cross two dimensions. A typical case is where you want to restrict modification to a combination of a Version and a Period. For example users can provide Actuals for June, and Forecast from July to December.

(Having said that at the risk of sparking another 1 vs 2 debate, I would always recommend a combined Year-Period dimension. I am working with a system that has separate Year and Period dimensions and it makes everything much more complex for both users and developers)

In your case you only seem to need to restrict security on one Dimension - Period.

You should be able to do this with }ElementSecurity_Period.

I would recommend that you have one Security Group of which all members are users. If you haven't already got this, then, this is a typical way to set up security. You have a general Group that gives the basic read access to Cubes, etc, and then more specific Groups to grant additional rights. Any user of the system is made a member of the General Group and then some users are made members of other Groups that give additional rights. They will always get the highest right of any Group of which they are a member. (The exception is CellSecurity which overrides Cube, Element, etc, security)

The rule that you were writing in the CellSecurity would have put the same security rights on all Security Groups which can be quite an overhead, depending on the number of Groups.

Once you have the General Security Group set up your rule should then be something like

['GenGrp']=S:
IF( dimix( 'Period' , !Period ) <= dimix( 'Period' , DB( 'Info' , 'Any', 'Current Period' ) )
,
'READ'
,
'WRITE'
) ;

Of course if you have separate Year and Period dimensions, you will also need to check the Year as well.

Purists will probably prefer an attribute rather than dimix, but I always generate time dimensions so I have full control over the element order.

Regards

Paul Simon

[SBK88]

Thanxx everyone..... issue resolved

prob was that I was logged in with the admin user.

Thnxx declanr, qml and paul for ur replies.