Securing a Dimension

[Former Member]

Hi,

What does securing a dimension during assignment of dimensions to an application mean?

And if i just secure it without putting a R/W to it, it doesn't seem to do much purpose. Please correct me if i am wrong.

Cheers

Edited by: lip chean soh on Oct 7, 2008 11:18 AM

[sorin_radulescu]

Assign secure to a dimension from an application means you need to restrict the access of users to that dimension.

Into Member Access Profile you can define for teams or users

1.what members they are allowed to see from that dimension

2.If an user is able to read or write which means an user is able to see data but may be he is not allowed to insert or modify data.

So you have to secure a dimension only when you would like to put some restrictions for some of users related to that dimension.

Regards

Sorin Radulescu

[Former Member]

Hi Leap,

It is used to secure the dimension, for example in case of Category Dimension, you can give Read/Write access to "Budget" category and Read Only to "Actual"Category.

If you grant read/write access, the dimension automatically becomes secured. If you have a secured dimension and Read/Write access, disabling Read/Write will not unsecure the dimension automatically; you will have to unsecure the dimension additionally

Hope this helps!

Cheers,

Umesh

[Former Member]

Hi,

Does that mean if a dimension is merely secured (i.e. without R/W activated), then it doesn't serve any purpose?

Cheers

[sorin_radulescu]

Secure and Read/Write access are two different conecepts:

Lets suppose you have dimension 1 where you have member A like father to B and C in your dimension.

Secure means that I'm able to provide access for an user to dimesnion 1 only to member C. He is not able to see any other member except C.

Now Read and write means the user can see only C but I can restricted his write access. He will not be able to send data or change data for C. He will be able only to see data for C if I will say for user he is able only to have read only.

Secure is reffering to access to members of that dimensions.

R/W is refering to possibility of changing data.

Regards

Sorin Radulescu

[Former Member]

Hi,

Why is there an error message "There is a problem in dimension file : ACCOUNT" in BPC for Excel if i do a "secure" and "R/W" on ACCOUNT dimension?

Actually this error message seems to happen to every dimension except for "Category" and "Entity", any idea why?

Cheers

Edited by: lip chean soh on Oct 9, 2008 12:05 PM

[Former Member]

I did some tests and i think using "secure" is the same as assigning "R/W" rights to a particular parent or member.

Hence what's the point of "secure" then?

[Former Member]

Hello,

Securing a dimensions allows you to control access to the members of that dimension. You will only have access to the members you were specifically given access to.

For the dimensions that are secured, you can, in addition, decide to be more specific and also control Read and Write access. This is usefull to give read only access to members of a dimension.

Let's look at 2 examples.

1. My dimension Entity is only secured (no R/W control)

In the Members access profile, I will have the following

Access Dimension Members

ReadOnly Entity France

This means that I will have read and write access to the member France (and all it's decendants), because this dimension has now read/write control. What is confusing here is that you have to select ReadOnly (this is the only possible selection when the R/W is not used for a dimension)

2. My dimension Entity is secured and has R/W control

In the Members access profile, I will have the following

Access Dimension Members

Read&Write Entity France

I will also have read and write access to the member France and it's descendants. I could however here specify "ReadOnly" and would then only have read only access to that members. To write back figures, you need to have "Read & Write" for all dimensions that have R/W control enabled.

Regards,

Marcel

[Former Member]

Hi Marcel,

What you said is true. But what i am trying to say is "Secure" + "R/W" can do EVERYTHING that a simple "Secure" can, and more (i.e. give some dimension just the "Read" rights). It's like saying i have a 10 function swiss army knife and a 5 function swiss army knife, i have all the 5 functions in that 10 function knife. So what's the point of having that 5 function swiss army knife.

Hence the question remains, what's the point of "Secure"?

And another question that just came up goes like this, assuming there are 3 accounts, i.e. finance, hr, everything else. And there are 3 enities, i.e. finance, sales, hr.

A finance department would have read and write rights to "finance" and "everything else" for account, read rights to "hr" account and read and write just for "finance" entity.

A sales department would have read and write rights to "everything else" account, no rights to "finance" account, read rights to "hr" account and read and write just for "sales" entity.

A hr department would have read and write rights to "everything else" account, no rights to "finance", read and write rights to "hr" account and read and write for all departments for entity.

Is the above possible? The problem is with the hr department and the entities. I want Hr to have the rights to change "hr" account for all entities but not for the other accounts but if you have read and write rights for all entities (to change "hr" account) to the hr department, it'll invariably give hr department read and write rights for all the other accounts for the other departments.

My apologies for rambling.

Cheers

[Former Member]

The point of Secure versus R/W Access is typically used for the groups of users who require access to members, but do not need Write capabilities. Prior to having the TASK profiles where we control the ABILITY to write, you needed a method to control access to view and have your CV populated properly to "WHAT" a user is SECURED to see (which is why I would also term it a VIEW RIGHT)So, if a group or user has Secure access, but no R/W access. they will get those members in their CV for use in the client. However, they cannot send any data back to the system; only retrieve. The two settings may be blended as your example points out, but the highest secured memebrs in the hierarchy will trump in access. But the assumption that you state, that departments have "Fixed" accounts that ONLY they can send data to is

So in the example:

FINANCE DEPT ACCESS LEVELS:

- FINANCE ENTITY R/W

- HR ENTITY, R

- Account - FINANCE R/W

- Account - EVERTHINGELSE R/W

- Account - HR, R

SALES DEPT ACCESS LEVELS

- SALES ENTITY, R/W

- Account - EVERTHINGELSE R/W

- Account - HR, R

HR DEPT ACCESS LEVELS

- FINANCE ENTITY R/W

- HR ENTITY, R/W

- SALES ENTITY, R/W

- Account - EVERTHINGELSE R/W

- Account - HR, R/W

Assuming NO hierarchies and flat levels, the HR department has access to change the Everythingelse account and HR account in all 3 depatments. The security is a matrix, not an assignment. Also, if you have certain FUNCTIONS in a business that want more security, then I suggest building a seperate cube, so that the secured dimensions and the intersections accross other organizations are controlled at the CUBE level. So, FUNCTION like HR, may need its own cube, so as not to interfere with other FUNCTIONS and the security. But the accounts above are not assigned to the department, rather the matrix of access both Read and Read/Write and DENY, provide the ability to VIEW or Write to combinations in a CUBE.

Hope this helps

[Former Member]

What i am trying to do for HR department is that it can read and write the HR account for sales and finance department, but it shouldn't be able to read and write the everythingelse account for sales and finance department, i.e.

hr account, sales entity - R/W

hr account, finance entity - R/W

hr account, hr entity - R/W

everythingelse account, sales entity - no rights

everythingelse account, finance entity - no rights

everythingelse account, hr entity - R/W

Even if you put HR in another application, can the above be done? I think the problem happens with the access of everythingelse account, i.e. should it be given R/W access so that the HR department CAN input everythingelse account for its own department, or should it not be given R/W access so that HR department CAN NOT input everything else account for sales and finance department.

cheers