Quantcast
Channel: SQL Server Analysis Services forum
Viewing all articles
Browse latest Browse all 14337

Defining cell security in a writeback cube

$
0
0

Hi all,

I am working with a cube containing a writeback partition with writable budget&forecast measures.

I want to control what dimension data users can see and I also want to control for which cells in the cube they can write back data.

Based on information in this excellent article by Greg Galloway, I have set up a ReadAll-role and a Writeback-role. I have added my testuser-account as a member of both roles. The ReadAll role is just what it seems, a role that gives the user access to the cube without any specific dimension or cell security applied.

In the writeback-role I want to, for example, secure cells for past time-periods in the time dimension. My time dimension has a single user defined hierarchy built up by the following levels: Year -> Quarter -> Month -> Day.

I have constructed the following MDX code in the "Cell Data / Enable read/write permissions" context:

Ancestor([Calendar].[Calendar].CurrentMember, [Calendar].[Calendar].[Month]).MEMBER_KEY > '201302' 

What this does is it successfully secures the writeback operations allowed, so that writeback is only allowed for months (or days) occurring after February 2013. I have tested this in Excel and it works as expected. If I understand correctly, you cannot work with sets in the expression for cell security, and that is the reason for using the somewhat awkward expression "MEMBER_KEY > '201302' above, instead of a perhaps more elegant set-expression using the range-operator (:). Pleas correct me if a have misunderstood this.

What I am struggling to understand is how I should construct the MDX so that it covers not only months, but quarters and years also. Let me explain what I mean: If, when trying to write back data, the currentmember of the time dimension is on a month-level or below, the above MDX works fine. Indeed, using Excel, I can only write back data if the current month (or day) is later than February 2013.

But of course, writeback should also work if forecasting on for example the Quarter or Year level of the time hierarchy. So, given the example that I secure writeback only for "time" after February 2013, Quarter 1 of 2013 (Jan/Feb/March) should of course be secured, since it contains time periods less than or equal to February 2013. But for all quarters after Q1 2013 writeback,should be allowed. But how should I construct the cell security MDX for this?

The MDX above does not work/apply when currentmember is on a higher level than month, since neither Quarter nor Year has an Ancestor the level [Month].

So then, I identify the need to having to specify an OR statement in the MDX cell permissions for each level in the time hierarchy.

Something like

Ancestor([Calendar].[Calendar].CurrentMember, [Calendar].[Calendar].[Month]).MEMBER_KEY > '201302' -- Key for Feb 2013

OR

Ancestor([Calendar].[Calendar].CurrentMember, [Calendar].[Calendar].[Quarter]).MEMBER_KEY > '20131' -- Key for Q1 2013

OR

Ancestor([Calendar].[Calendar].CurrentMember, [Calendar].[Calendar].[Year]).MEMBER_KEY > '2013' -- Key for 2013

If I understand correctly this should then (I have not tried it yet) make cell security work in the intended way, no matter which level in the time dimension the user is when trying to write back data. If you are on a month you must be on a month after the one which is our "limiting month". If you are on a Quarter you must be on a quarter starting with the "quarter immediately after the one to which our limiting month belongs". For month limit = "after February 2013" this gives that the first allowed Quarter should be Q2 2013 (Apr/May/Jun). And similarly, if you are on a Year level you must be on a Year starting with the "Year immediately after the one to which our limiting month belongs". In our case this gives Year = 2014.

But even if this works I am really unsure whether this is the best way of handling the requirements. It feels a bit un-elegant?

What I really is after is a simpler cell security MDX expression that states that, independent of level in the hierarchy to which the "limit member" belongs, writeback is allowed for all time "after"this member. In my example: Days, Quarters, Years "after" February 2013.

I would be really thankful for any input on this and how to handle it. Hopefully  there is a much easier way of how to think about this and handle it, than I can image right now. Is there a better way of handling this that does not involve cell security?

(Note: I am aware of the concept of "dynamic" dimension / cell security, but I would like to leave that out as of now, since I don't think that is the main challenge for this specific problem).

Thanks

Martin





Viewing all articles
Browse latest Browse all 14337


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>