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)
In development, it looks like this: (UNflag to hide design-feature)
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.