Meet All Your Possibilities

Choose a category to find the help you need

01.

FAQ's

FAQs can help you quickly to find what you need.. have a look at them.

02.

Video Doc

Google receives morethan 40k video searches in a minute.. no doubt, there are the perfect way to quickly understand the process. Hence, we have some videos  for you too..

03.

knowledge Base

When it is required to explain in better, we have a Knowledge base article added for you. It explains more in-detailed, gives you references and links to review.

04.

Community Forum

Still haven’t found the answer? No problem, use our community forums where we have 1000+ experts working 24/7 to answer your questions.. add one and wait for our expert to respond.

Frequently Asked Questions

read some regularly asked questions

Do I need to assign these authorizations manually every time I create a new user?

Assigning privileges individually is not either SAP or industry recommended approach due to complex maintenance of privileges. The alternative and best approach to manage the privilege assignment is through “The Privilege based roles” and assign these to the users.

Why I am getting numerous errors while assigning privileges/roles?

This is quite common, if all the relevant privileges are not assigned to the user & when the _SYS_REPO user doesn’t have authorization to grant them to the user. Please note, _SYS_REPO is the global granting guy. Any object that you wish to grant to the users should be assigned to _SYS_REPO first with grantability option.

Let me explain in-detailed. The owner of the object (role, or a privilege) can only assign it to the other users. Incase if you are granted with the authorization to assign to object to other users, you will be able to assign it without any errors. This mostly happens with the objects that are owned by SYSTEM, and SYS. Hence, it is always recommended to create the objects in design-time and activating them would assign the object to user SYS_REPO.

Option # 1 – After implementation, create a master admin ID and assign all the SAP delivered roles, and privileges with “Grantable to others” option to yes. (Not recommend)

Option # 2 – Create a role in design-time with the relevant SAP delivered roles, and privileges and activate it. A role that you create in the HANA system can have the SAP delivered roles and privileges. This can be assigned to the user by any of the Security admin as the activated objects doesn’t look for Grantability option.

How do I assign an activated role to the user directly?

After activating the design-time role definition, you can grant the resulting runtime role object to application developers, for example, by executing the _SYS_REPO procedure GRANT_ACTIVATED_ROLE. The call requires the parameters: ROLENAME (the name of the runtime role object you want to assign) and USERNAME (the name of the user to whom you want to assign the new runtime role).

call “_SYS_REPO”.“GRANT_ACTIVATED_ROLE”(‘Role name’,’User Name’);

How do I create the role & what privileges are required in the role?

Before creating a role, please note that the role can be either a Repository Role or a Catalog Role.

Below are the steps to create a role in Catalog (Run-time) mode:

To create a role:

  • Right-click on Security, Role and select New role.
  • Then assign the relevant privileges/roles and publish the roles.

Below table gives you a quick understanding on which privileges are required for every target user:

hana_roles

A role in the Repository (Design-time) mode can be created from the Project Explorer.

What are the differences between a catalog role and a repository role?

When you create a role in Run-time, the owner of the role will be the creator only. Incase if other users should get authorization to grant this role to any other users, then the owner should provide that authorization.

When a role is created as a repository role, the repository version belongs to the owner, and the activated version (run-time) belongs to SYS_REPO.

GRANT_ACTIVATED_ROLE privilege in HANA gives authorization to users to grant Repository roles that are owned by _SYS_REPO.  Below are the differences between a Catalog role and a Repository role:

Catalog and Repository Roles

How do I create roles in Design time (Repository Roles)?

To create roles in design time, you need to have a project created under the Project Explorer. Note that the Administration perspective will allow you to create only run-time roles. To create the design-time roles, you need to be in the HANA Development perspective.

How to identify the effective privileges of a particular user?

Use the below SQL statement:

SELECT * FROM “PUBLIC”.”EFFECTIVE_PRIVILEGES” where USER_NAME = ‘RAGHUB’;

How to identify the current Analytic Privileges assigned to a particular user?

Use the below SQL statement:

SELECT * FROM “PUBLIC”.”EFFECTIVE_PRIVILEGES” where USER_NAME = ‘RAGHUB’ AND OBJECT_TYPE = ‘ANALYTICALPRIVILEGE’;

I am unable to view the details of other users using SQL statements. Do I need any special authorization?

You need a database user with either DATA ADMIN or CATALOG READ system privilege to query about other users. All users can query their own data, no special privileges required for the same.

When I’m assigning authorizations, getting the following error: "Could not modify user RAGHU_TR1’. Could not grant privilege 'SELECT' on 'ACTIVE_OBJECT (_SYS_REPO)'. Can only grant privileges for objects in content schemas"

Instead of using the authorization management tab, grant the SQL privileges via SQL commands.

Examples (replace <user_name> by the name of the user or role that should receive the privilege):

grant SELECT on _SYS_BI.BIMC_CUBES to <user_name>;
grant SELECT on _SYS_BI.BIMC_DIMENSIONS to <user_name>;
grant SELECT on _SYS_BI.BIMC_PROPERTIES to <user_name>;
grant SELECT on _SYS_BI.BIMC_VARIABLE to <user_name>;
grant EXECUTE on SYS.REPOSITORY_REST to <user_name>;
grant EXECUTE on _SYS_REPO.GRANT_PRIVILEGE_ON_ACTIVATED_CONTENT to <user_name>;
grant EXECUTE on _SYS_REPO.GRANT_ACTIVATED_ANALYTICAL_PRIVILEGE to <user_name>;
grant SELECT on _SYS_REPO.OBJECT_HISTORY to <user_name>;
grant SELECT on _SYS_REPO.ACTIVE_OBJECT to <user_name>;
grant SELECT on _SYS_REPO.ACTIVE_OBJECTCROSSREF to <user_name>;

What is the basic difference between Regular user and a Restricted user?

Regular user can use HANA Studio & Web IDE to login to the HANA DB. Wherein, a restricted user can login only thru the Reporting tool/component.

What are the common authorizations that needs to be assigned to every user?

Below are the common authorizations that are required by every user:

  • SYS_BIC (Object Privilege) with SELECT
  • SYS_BI (Object Privilege) with SELECT
  • PUBLIC (Role) ** Only required, if the user has to login to HANA through HANA Studio, or Web IDE.
  • REPOSITORY_REST (Object Privilege)

** SYS_BI_CP_ALL (only if the user is an admin or a developer) – This privilege gives authorization to all the classical Analytic Privileges.

Why should we not assign the Public role to the restricted user?

Because, public will give authorization to view all the catalog objects. Since a restricted user shouldn’t view them thru any means, we don’t assign this authorization.

Why do we need Analytic Privileges?

Analytic Privileges will limit the authorization of the users on a specific Information View (IV). The same IV can be assigned to multiple users with different authorizations. For eg: User A when executes the IV, he/she will only see the data related to one region, and User B is restricted to a different region.

In simple, Analytic Privileges are used to restrict the user authorization on specific sub-set of data.

What are the basic requirements to create an Analytic Privilege?

To create an Analytic Privilege, you need:

  • Information View (CVs)
  • Type of AP that needs to be created
  • Object (Attribute) on which restriction should be applied
  • Restricted Value

What are the different types of Analytic Privileges?

Conceptually there are 3 types:

  1. SQL Based
  2. Classic AP
  3. Dynamic APs (Stored procedure) which assigns authorization to either SQL or classic AP. Hence it is not considered as a type of AP.

Technically, there are only 2, SQL Based, and Classic (XML)

NOTE: On a particular IV, you can either have SQL based or XML based APs. Information view can’t have both the APs.