cube visibility / grant cubes

Khaleelah · 2024-12-10T18:03:41+00:00

There was an error rendering this rich post.

Khaleelah

Dear Team,

Currently exploring the cube visibility / grant cubes at link below

Cube visibility

i have some difficulty understanding the grant cubes and how they are used and when they should be used.

Do we need to create grant cubes and how many do we need to create and based on what.

The link also speaks of an adminstration screen , what are the cubes used on the screen.

Grateful for some clarity.

An example would be most welcome

RGds

Find more posts tagged with

Accepted answers

All comments

Helmut Heimann

Dear @Khaleelah ,

the grant cubes usually are based on entities in the organizational structure (i.e. Cost Centers, or branches). They can be cubes of your reporting groups, or they can be additionally created to control access to specific areas.

If, for example, you have defined security based on the entity "Cost Center" (specific users have access to specific Cost Centers) you could use a reporting cube dimensioned by "Cost Center" as driver for the grant access. Otherwise, you might need to create a cube dimensioned by "User" and "Cost Center" to define the access.

For the second one, you'd need an admin screen to specify allowed combinations for access.

Hope that helps,
Helmut

Khaleelah

Hi Helmut,

Thank you very much for your prompt reply.

If my understanding is correct, the grant cubes in the second option (cube dimensioned by user and cost centre) will normally be used on the following screen

And Grant Cubes will be created based on the business user security requirements (otherwise we might not require them)

Am i correct?

Rdgs

Khaleelah

Helmut Heimann

Hi @Khaleelah ,

the access permissions are defined in the screen which screenshot you provided, regardless of whether the cube has the user dimension or not. If it does not have the user dimension, you'd need user security on one of the cubes' dimensions.

Whether or not required, the grant cubes allow for a more granular level of security and even on dimensions that are not part of the user security.

One example for that is that a user might be allowed to see planning data for all Cost Centers but they should only be allowed to edit a specific one—that's something you can't achieve with standard user security.

The example in our Knowledge describes such a scenario pretty well:

https://help.board.com/docs/new-cube-visibility-feature

Best,
Helmut

Khaleelah

hi Helmut,

I will try same.

Regarding folder security, i do understand that we cannot apply security on subfolders (screens) of a particular capsule or we do not have screen access security. But we can control what the user sees as data by configuring the cube visibility etc.

Do you have any recommendation how i could address the issue of screen folders. For example in below screenshot, if i do not want a user to have access to the submenu Price. What design would you recommend as a workaround.

PS: I am now only exploring the menu object and taking into consideration its limitation, I want to know the best practice.

Thanks

Helmut Heimann

Hi @Khaleelah ,

unfortunately, you can't achieve security on that level with the Menu object. That is not in any way related to security settings.

I would advise the use of Label objects for navigation in that case. But I must tell you that such an approach will require additional maintenance.

You will need a cube dimensioned by "User" and "Screen" which will be populated by Datareader or using an administrative screen (you'll need the screen anyway to maintain the user rights to access specific screens).

The according label which will let the user jump to a specific screen, will have a layout containing the "User-Screen" admission cube to control the visibility and executability of the label itself. Its action value will be the screen's name.

Additionally, you could design a dataview to achieve that (might be easier to handle)—but sometimes the label will be prettier to look at.

Best,
Helmut

Khaleelah

hello Helmut

Users are not happy with the labels , this design already exist.

I was wondering if when the user clicks on a menu , then a procedure checks at the opening trigger of a screen if the user has acess to the page. The problematic is that i would need to write a procedure for each screen (since the concept of passing parameters to a procedure does not exist)

or create subfolders in capsules !!!

What is your opinion?

Rgds

Khaleelah

Helmut Heimann

hello @Khaleelah ,

the on-open trigger could be a solution to that. But you would need any administrator to be present in the users cube and you can't apply a security selection for admin users (or rather you should not do that).

The procedure can be just one: it uses the "@Screen" substitution for comparison.

The admin users would not automatically be selected (by @user) in the security script and therefore you'd need a small addition in your procedure with a select-cube for the user (which can be a temporary cube). This cube would hold a "1" for each user and the aggregation of that would be 1 for a "normal" user and >1 for any adminstrator—in that case a user has to be interactively selected before the procedure goes on.

Best,
Helmut

Khaleelah

interactively selected ? meaning?

Rgds

Helmut Heimann

Hi @Khaleelah ,

I mean the procedure action "Interacive Selection". You can find more on that topic in our Knowledge Base:

https://help.board.com/v14/docs/select-action-group#interactive-selection

Best,
Helmut

Khaleelah

i know, but im not sure it will be appropriate and user friendly.

Lets see..

Helmut Heimann

https://community.board.com/discussion/comment/19231#Comment_19231

That's only necessary for admin users, all others will have their username selected automatically by @user in the custom select script in the security settings.

Best,
Helmut

Khaleelah

oh ok, then it should be ok.

Will try to simulate all these ideas and present to the user. A mixture of visibility cube/ procedures .

Thanks a lot

Helmut Heimann

Hi @Khaleelah ,

you're completely correct—in the end it will always be a stakeholder's decision.

Best,
Helmut