Client Constraint during configuration of Pega 7 post the upgrade
The question is around the privileges of the user role using which Pega has been configured after the upgrade.
One of our Clients have upgraded by giving deployment user temporary admin access, but later during configuration following occured.
What is Client Constraint?
Client has security constraint of not providing a DB user with full admin access to both Rules and Data Schema.
What Client provided:
During upgrade, on a temporary mode full admin access was given to the deployment user using which the upgrade scripts have been run.
Now during configuration - they created a Base User role which is only having DML access on both Rules and Data schema and using that the Pega has been configured. All cross schema privileges generated during cross schema granting has been revoked as well.
As a result of the above-stated configuration, team is experiencing issues like table creation, framework installation from application end.
We mainly want to confirm, will the mentioned configuration also impact any product behavior/operation to support split schema mode. Also as cross schema grants have been removed, will those impact Pega running in split schema.
Whether the base user need DDL privilege forever in application (During upgrade and after upgrade) or just during upgrade process? Once upgrade process done (once time activity) DBA can remove DDL privilege and provide only insert/select/update/delete privilege (DML) on data and rules tables.
2nd thing execute stored procedures in data and rules schema, this is a onetime activity or it may happen anytime while the application up and running in production based on application use (end user task /background process).
I feel base user should not have DDL privilege in higher/lower environment once application is upgraded from V6 to V7, please put your thought here.
Base user does not require the DDL privilege. The user which is used during the upgrade process requires the DDL and DML privileges.
If you have used same Base user during the upgrade process then you can revoked the DDL privilege.
Stored procedure are used through out the application even after the upgrade. So the base user should have a privilege to execute the stored procedures and functions in both rules and data schema. Without this configuration your application will not work properly.
One more doubt the stored procedure internal executing some DDL activity , if the base use don't have DDL privilege after upgrade and the same stored procedure is calling from application then below exception is showing in log .
SPPR_DEFRAGMENT_TABLE procedure: calling from application, which is performing some DDL’s is throwing error in application logs. Input to this procedure is table_name and schema_name. Not sure what are all the inputs the application is passing. Throwing below error..