Selective Version Access

[jv_oz]

Another interesting conundrum!   ???

We need to add a new version for the Corporate Budget, i.e. what we submit to our parent, in addition to our normal Budget that is used for local management.  The Finance people do not want the general users to see this new Corporate version.

From what I understand, if you have read or write access to an elist node, you can pretty see or change the contents of it and you can't restrict access to say, a version within an elist item. 

That being said, what I have tried is creating a Saved Selection which included only the top level of the elist, then creating an Access Table with all child categories of the elist Hidden for the Corporate version, giving write access to the Corporate version for the Saved Selection and assigning Review rights down all levels to the group with top level access.  Unfortunately it didn't work.  The result was that the Corporate version was not visible at all (which makes sense given that the Access Tables seem to aggregate up rather than trickle down).

We had also considered copying the models, however we have a rather complicated incremental update process between the models that would be awkward to duplicate, so would prefer to keep it all in a single set of models.

So, any ideas out there?

[StuartS]

I assume you need to have the relevant people have edit access to the corporate budget.

The solution in my mind would be to do the following.

Add a D-List with two items, Budget and Coporate Buget.  Add to all relevant cubes.

Double the number of elist CHILDREN. 

e.g.

PARENT
---A Budget
---A Corporate

NB:  regarding reporting as well as adding a child you could add a new parent that is then HIDDEN in BP, but if course can be used for reporting in BI.

e.g.

PARENT
-A Parent   HIDDEN in BP
---A Budget
---A Corporate

Control HIDDEN access by elist item to this 'version' D-List.

Cons of course mean that your model increases in size, but this is a way to get it all in one model.

Does this provide a way forwards?

Stuart

[mrobby]

Stuart has the right idea here as you are not allowed to set security on d list items, only e list.  Another option is obviously a copy of the model with an admin link between the two.

[StuartS]

Yes, that was my other thought :)

[overflow.au]

A note of caution - aggregations could be misleading, unless the only data in the Corporate eList items is in Corporate version, with zero data for all other versions in these eList items.

It could mean that adding the eList items for Corporate would also need to review hierarchy - for example:

PARENT (Local)
---A Budget
---B Budget
PARENT (Corporate) (Visible / writeable only to finance groups)
---A Corporate
---B Corporate

Other query would be in terms of model size - what is the benefit of doubling the size of the relevant cubes (by adding a dimension), instead of increasing the size of the current Version dimension, which can be identified against the eList in the access tables?  This would set the corporate version for all local eList items, and all other versions for corporate eList items to zero data.  Access tables would then only provide visibility to the corporate elist items appropriate to their finance group requirements.

[adityashah27]

it looks like the business/planning process justifies the separate models. you have different usergroups, both versions have diff objective and meaning, timing could be diff (i.e. opening and locking versions) and no transfer of data between models. for corp budget, finance group might need more summarised information. in this case, if you have two models, you have flexibility to customize it for finance guys.
otherwise solutions mentioned above can be implemented but it will add up the sustainment time in managing dynamic elist and access tables.