1. Security Management Logic

Security Management is split by Role dans Scope depending on the object you want to give users access to.

1.1 Role

One user needs to have at least one role (but can have multiple ones).
The role is concretely a user group.
The objective behind is to give access to Workspaces (Remote and/or Web), Models, Shortcuts.
The list of roles by GBU has been defined and should not changed frequently.
For example: two users can be Sales Manager for one GBU - they will see the same workspaces, shortcuts, models... The process will be identical.

1.2 Scope

One user needs to have one scope/perimeter only (in order to avoid conflict/blocking between several users.)
The scope is concretely a user group.
The objective behind is to give access to a specific list of DFUs or any other dimension (depending on an aggregated level).
The scope is changing frequently depending on Commercial Team organization in SAP/GBU.
For example: two users can be Sales Managers for one GBU but with two different scopes - they will be able to work on the same workspace at the same time on a different set of DFUs.

Where should we define the Security : the real answer is that it depends on the user and what is the screen he's supposed to see. To make it simple, the user should have his Security defined in the dimensions (Master tables) of the datafields shown in his screen + in the User models the datafields are stocked.

In Solvay DP Context,

> Master table: most of datafields have the Material:Shipto@DC dimension, so the Security would need to be defined at least in this Master Table (in most cases).

> User groups: an user for a GBU will have access to the "Forecast model lvl 1" (standard model where most datafields are stocked) + User model of the GBU (ex: user from Perox GBU will have access to "Perox User Model")

Example of access to Master Tables

Ex1: in the following grid view, all the DFs have Horizon + Material:Shipto@DC dimensions => user should have the right Security defined at Material:Shipto@DC (note: we don't define Security in Horizon)

SBS - DynaSys Team - Techno > 2. Security Management > image2021-6-3_9-47-27.png

Ex2: in the following cases, even though there are several splits of Material:Shipto@DC (Soldto, Country,...), we still just have to define the Security in the root (before split) Master table: Material:Shipto@DC

SBS - DynaSys Team - Techno > 2. Security Management > image2021-6-3_9-50-4.png

Ex3: in the following cases, we have to define the Security in Sales Employee ID table,

SBS - DynaSys Team - Techno > 2. Security Management > image2021-6-3_9-52-3.png

What do we need to do a Security: to define the Security, we need a condition (True / False). Most users of DP are Sales employee, each of them having a Sales employee condition associated.

2. Security by GBU

2.1 Workspaces

2.2 Models

2.3 Shortcuts

2.4 Master Tables

3. Examples

3.1 Example #1 - Simple

For ex: for a Sales Employee of a given GBU

#	Description	Screenshot
1	right click the master table Sales Employee ID, then click Security, In the Advanced security tab, for each user group, associate the conditions to the corresponding user groups,
2	right click the master table Material:shipto@DC, click Security, In the Advanced security tab, for each user group, associate the conditions to the corresponding user groups,

3.2 Example #2 - Complex

For example, QSM-285899

#	Description	Screenshot	Reference view
Problem Reporting!
1	user SANTOSMA all black view while open the work space,
Trouble Shooting!
2	The grid view has a split on dimension Material:Shipto@DC into Country Ship-To Sold-To Material and the original data field dimension, Material:Shipto@DC
3	If you connect as the user into the rich client and right click => Configure on the view, you can check which one is empty (the one with /) :
4	The problem is on Material : the view has a filter on Material, on condition 'GBU - TS: Yes & Planned Material \| TS : Yes' :
5	User belongs to those groups :
6	The only group having a security configured on the master table 'Material' is TS - US / Marcio Santos, with the visibility condition 'GBU - SA&D' Finally, a right click => hierarchy view (with a super user account) on the master table 'Material' shows that there is no intersection between the combination of the conditions used to filter the grid and the condition of visibility :
7	select here the 3 conditions (pressing control key allows to multiple select them) :
8	And we can see that no material fulfills the 3 conditions :
Fix!
9	The problem is on Material : the view has a filter on Material, on condition 'GBU - TS: Yes & Planned Material \| TS : Yes' : The only group having a security configured on the master table 'Material' is TS - US / Marcio Santos, with the visibility condition 'GBU - SA&D' To remove the condition 'GBU - SA&D' in Material table associated with user group TS - US / Marcio Santos

4. Useful documentation

QAD Documentation