Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

SA

Former Member
0 Kudos

Hi,

I also need to know about the Maintaining Authorizations for Hierarchies.

Bye

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Hi,

Maintaining Authorizations for Hierarchies

Before you can make authorizations for hierarchies, you must first transfer and activate the Info Object 0TCTAUTHH from Content. Make sure that the indicator relevant for

authorization is set. You must also create an authorization object for which you want to make the authorization.

1. Choose Business Explorer → Authorizations → Reporting Authorization Objects.

2. Choose Authorizations → Authorization Definitions for Hierarchies > Change.

3. In the Definition, select the InfoObject, hierarchy, and node.

4. Select the Type of authorization:

0 - for the node

1 - for a subtree below the node

2 - for a subtree below the node up to and including levels for a subtree below the node

3 - for the entire hierarchy

4 - for a subtree below the node up to and including levels (relative) (You must specify a level that is defined relative to the node for this type. It makes sense to specify a relative distance if an employee may only expand the hierarchy to a certain depth below his initial node, but this node is moved to another level when the hierarchy is restructured.)

5. Specify a technical name for this definition. If you do not enter a value, a unique ID is set.

6. Now create an authorization for the new authorization object. To do this, enter the technical name of the definition as a characteristic value for the characteristic 0TCTAUTHH. For the characteristic defined on the hierarchy, specify the value" ." (blank). It often makes sense to also enter ":" (colon) so that queries without this characteristic are also allowed.

Hint: If you enter the value "*" here (all characteristic values), the user is allowed to view data for all characteristic values, regardless of whether a hierarchy is used or a complete drilldown is carried out.

7. Optionally you can use the following fields:

• Top of hierarchy: This option allows you to select the top of the hierarchy instead of a node in the hierarchy.

If, for example, you want to authorize a user to work with a hierarchy from the top node, down to a particular level, you can of course authorize the user for the highest node in the hierarchy. If, on the other hand, the hierarchy is used in the query without a filter set for this node, the user is not able to execute the query.

This is because the node that is displayed at the highest level in the hierarchy, is not actually the top of the hierarchy. For example, there is the .All Other Leaves. node. This is an internal node, but a node in the hierarchy nevertheless, and it is this node that is at the top of the hierarchy, a level higher than the highest node that appears in the hierarchy display. If the hierarchy is used in the query, and the top-level node has not been specified explicitly, the system checks the authorization against the highest node in

the hierarchy, meaning the internal node that is not displayed. This option, therefore, allows you to determine the top-level node of the hierarchy yourself, so that you can ensure that users are assigned the appropriate authorizations.

• Hierarchy level : Within the framework of the authorization check, you can use this value to specify to which level the user can expand the hierarchy.

Please note that this is an absolute value and refers to the entire hierarchy. The highest node of a hierarchy stands at level 1. If you have entered the value 3 for the hierarchy level, for example, then the user can expand/see the hierarchy up to level 3.

• Validity period : 0: Name, Version, and key Date identical

1: Name and version identical

2. Name identical

3. All hierarchies

• Node variable default value: If this option is chosen, this definition of a hierarchy authorization is used as the default value for node variables.

If a user is allocated several authorizations for subareas of the same hierarchy, one of these authorizations must be defined as the default value in this way. Only one node can be chosen for a node variable in the variable screen of a query. In order that this variable be filled from the authorizations, the correct variable type must be chosen and an authorization must be marked as the default value.

Thanks & Bye

2 REPLIES 2

Former Member
0 Kudos

Hi,

Maintaining Authorizations for Hierarchies

Before you can make authorizations for hierarchies, you must first transfer and activate the Info Object 0TCTAUTHH from Content. Make sure that the indicator relevant for

authorization is set. You must also create an authorization object for which you want to make the authorization.

1. Choose Business Explorer → Authorizations → Reporting Authorization Objects.

2. Choose Authorizations → Authorization Definitions for Hierarchies > Change.

3. In the Definition, select the InfoObject, hierarchy, and node.

4. Select the Type of authorization:

0 - for the node

1 - for a subtree below the node

2 - for a subtree below the node up to and including levels for a subtree below the node

3 - for the entire hierarchy

4 - for a subtree below the node up to and including levels (relative) (You must specify a level that is defined relative to the node for this type. It makes sense to specify a relative distance if an employee may only expand the hierarchy to a certain depth below his initial node, but this node is moved to another level when the hierarchy is restructured.)

5. Specify a technical name for this definition. If you do not enter a value, a unique ID is set.

6. Now create an authorization for the new authorization object. To do this, enter the technical name of the definition as a characteristic value for the characteristic 0TCTAUTHH. For the characteristic defined on the hierarchy, specify the value" ." (blank). It often makes sense to also enter ":" (colon) so that queries without this characteristic are also allowed.

Hint: If you enter the value "*" here (all characteristic values), the user is allowed to view data for all characteristic values, regardless of whether a hierarchy is used or a complete drilldown is carried out.

7. Optionally you can use the following fields:

• Top of hierarchy: This option allows you to select the top of the hierarchy instead of a node in the hierarchy.

If, for example, you want to authorize a user to work with a hierarchy from the top node, down to a particular level, you can of course authorize the user for the highest node in the hierarchy. If, on the other hand, the hierarchy is used in the query without a filter set for this node, the user is not able to execute the query.

This is because the node that is displayed at the highest level in the hierarchy, is not actually the top of the hierarchy. For example, there is the .All Other Leaves. node. This is an internal node, but a node in the hierarchy nevertheless, and it is this node that is at the top of the hierarchy, a level higher than the highest node that appears in the hierarchy display. If the hierarchy is used in the query, and the top-level node has not been specified explicitly, the system checks the authorization against the highest node in

the hierarchy, meaning the internal node that is not displayed. This option, therefore, allows you to determine the top-level node of the hierarchy yourself, so that you can ensure that users are assigned the appropriate authorizations.

• Hierarchy level : Within the framework of the authorization check, you can use this value to specify to which level the user can expand the hierarchy.

Please note that this is an absolute value and refers to the entire hierarchy. The highest node of a hierarchy stands at level 1. If you have entered the value 3 for the hierarchy level, for example, then the user can expand/see the hierarchy up to level 3.

• Validity period : 0: Name, Version, and key Date identical

1: Name and version identical

2. Name identical

3. All hierarchies

• Node variable default value: If this option is chosen, this definition of a hierarchy authorization is used as the default value for node variables.

If a user is allocated several authorizations for subareas of the same hierarchy, one of these authorizations must be defined as the default value in this way. Only one node can be chosen for a node variable in the variable screen of a query. In order that this variable be filled from the authorizations, the correct variable type must be chosen and an authorization must be marked as the default value.

Thanks & Bye

Former Member
0 Kudos

Hi Marata,

In order secure hierarchies, there are several steps:

<u><b>1. Make the InfoObject for the hierarchy authorization-relevant.</b></u>

The InfoObject you are marking as authorization-relevant is the InfoObject on which the hierarchy is based. Additionally,the InfoObject 0TCTAUTHH must also be marked as authorization-relevant.

<u><b>2. Create a reporting authorization object</b></u>.

When creating the reporting authorization object, you must include

at least two fields: the InfoObject for the hierarchy (such as

0COSTCENTER), and the InfoObject 0TCTAUTHH. The InfoObject

0TCTAUTHH protects the hierarchy node.

<u><b>3. Use transaction RSSM to create an authorization for the hierarchy

node you wish to secure</b></u>.

This is the step that is most unique to hierarchies. In RSSM, you

create an authorization that is used to determine the exact node of

the hierarchy the user should be able to access. You must enter the

InfoObject, Hierarchy, and Nodes.

<u><b>4. Create a role that uses the authorization you created in transaction

RSSM</b></u>.

Use role maintenance to create a role that includes the authorization

object you created in Step 2. Once you bring in your authorization

object, the field value will be the authorization you created in Step 4.

<u><b>5. Link your authorization object to the appropriate InfoProvider(s).</b></u>

Linking your authorization object to an InfoProvider is a very critical

step. In this step, you will impact people currently executing queries

for the InfoProvider that is now related to your authorization object.

This linkage forces your authorization object to be checked when

ANY query tied to the InfoProvider is executed.

When setting up security for hierachies in transaction code RSSM you can

grant access to the Top of the hierarchy. In the field Type of Authorization you

can grant access to subtree below the nodes, only the nodes, the complete

hierarchy.

Please reward points if useful.

Thanks & Regards,

Santosh