Issue while activating Open ODS - fail to create scenario: [2950] user is not authorized

[former_member215470]

Dear Experts,

We are facing an issue while trying to activate an Open ODS Views. We are getting the issue -

insufficient privilege: fail to create scenario: [2950] user is not authorized;Details (Warnings):

Now this is a common issue, I know, which can be resolved by granting SELECT on the particular Schema to the user who is trying to activate the Open ODS View. We did that and the schema is being shown for the particular user under the 'Object Privileges' tab -

However, the issue persisted.

After a bit of researching on SCN, we did come across the fact that '_SYS_BI_CP_ALL' Analytic Privilege should be provided to the user who is trying to activate the Open ODS View. We provided that as well -

Unfortunately, the issue still existed.

We then checked the SAP Note - 1761917 and saw that the below resolution steps were there -

Thus, the _SYS_REPO user must have the privilege SELECT WITH GRANT OPTION for the schema used. However, when we check the _SYS_REPO user, we find that it is inactive and it doesn't have the particular schema under its Object Privileges -

When we are trying to provide the privilege of the schema to the _SYS_REPO user from the SYSTEM user, we are getting the below issue for missing privilege -

Could any of you please confirm two things to me?

(i) For activating the Open ODS View, do we need to change the current status of the _SYS_REPO user?

(ii) How do we grant the _SYS_REPO user, the privilege to access the schema in question. We tried executing the SQL statement (as shown above), as well as tried adding the schema under the 'Object Privileges' tab directly.

Any help in this regard will be highly appreciated, as we are currently stuck. Please feel free to let me know if I can provide any further details to give you more insight on this issue.

Many thanks in advance,
Sayan Dey

[RolandKramer]

Hello

Yes, this is almost the case, as by default this authorization issue with the _SYS_REPO user is quite common. This should be resolved if you follow the information in the document precisely

Best Regards Roland

[former_member215470]

Many thanks for pointing this out, Roland. We are checking this from our end now. Will be writing about the solution, once it is solved.