Skip to Content

A great new feature in the sap BI 4.X is the possibility to customize via a handy flag/unflag tree.  Everything works super until you have users that belong to muliple groups with different customization.  In my case I had a user who belonged to the key-user-group and also to the view-user-group.  The authorization of the view-user-group is the same as the key-user-group, except the design-feature.  The customization on the usergroup (hide “design”) should do the trick, I thought.  View-users not able to design and key users and view&key users able to design.  How wrong I was.  After apllying this, the user was denied to the design-feature.  After a good search I discovered why.

Note that our production environment is on BI 4.1 SP 1 Patch 4 and our development is patched to BI 4.1 SP 3 Patch 2.

Go to the Customization feature, by rightclicking on the group you want to customize and click on it in the CMC.

On CMC – production, customizing looks like: (flag to hide design-feature)

0000Capture.PNG

In development, it looks like this: (UNflag to hide design-feature)

0001Capture.PNG

First I laughed with this small adaptation.  But now I understand why they changed it.

The rule to customize, regarding multiple groups, is very simple. The first created group (has the lowest ID) will be apllied.

I checked my groups via properties and indeed the viewer-group had a lower ID then the key-user-group.  So that’s why the user still didn’t see the design-feature.  To resolve it I recreated my groups in the right sequence. Applied the customization on my viewer-group. Unfortunally this didn’t resolve my issue.  The user still didn’t see the design-feature.

Now, why the SAP developers have changed the FLAG/UNFLAG method?

Because the rule is: The first created group WITH CUSTOMIZATION will be applied.  My key-user-group should be able to do everything, so I didn’t touch customization there, I only created it on my view-user-group.  So in the latest version they flag eveything, so customization should take place as well on the untouched key-user-group.  But I think some programming went wrong because it still did not take place.  Only after removing (unflagging) a small, unimportant feature, activated the customization on my key-user-group, and fixed my problem.

To sum up: implementing customization on multiplegroups will follow the rule: The first created group with changed customization will be applied.

To report this post you need to login first.

6 Comments

You must be Logged on to comment or reply to a post.

  1. Nico 't Hoen

    Hi Koen,

    You cannot define customization for users, only for groups. When customization have not been defined for a group they are inherited from its closest parent.

    So it is NOT the first created group but the closest group, for the user, customization.

    (0) 
      1. Nico 't Hoen

        /wp-content/uploads/2014/07/customization_501002.png

        Usergroup “Refresh Users” and “Analyst Users” have Customization, applied.

        Every user belongs to the “Everyone” group. So in this case User “nico_t_hoen” inherites Customization from the usergroup “Refresh Users”.

        But user “Nico_t_Hoen” also belongs to the group “Analyst Users”

        Because “Analyst Users” is only 1 User Group away, the user inherites “Customization” of the usergroup “Analyst Users”

        Maybe when the user groups are on the same level,The first created group will be chosen to apply customization.

        So create a solid authorisation structure, future proof, without to many Customizations, good luck.

        (0) 
  2. Pablo Silvestro

    I’m a little bit confuse, is this feature replacing “application” (security) area on CMC?

    As I can see, you are defining application permisions directly in the group

    (0) 

Leave a Reply