After migration from QC 9.2 to ALM 11 problems with the group permissions

After migrating from Quality Center (QC) 9.2 to Application Lifecycle Management (ALM) 11 issues with the Group permissions could cause different problems.

Note: If the above is not the exact reason for using this fix, running this repairer will actually cause a security breach exposing this entity for update. This is a situation that needs to be avoided.

One such example would be that although a user belongs to a group with the permissions to create and update design steps, the user also cannot create a new design step by copy and paste. The ALM current permission model has a rule. If a group has the update permission over at least one of an entity’s fields that is exposed in the permissions User Interface (UI), it should also have the update permission over that entity. Before running this repairer there might be an entity with permissions to update its fields, but without permissions to update the entity itself for some group. In this situation, the entity is blocked in all or most use cases from being updated in the database (DB). After running this repairer this entity will have permissions for updating the entity. This means that in all use cases it will be allowed to update this entity. And also, on the contrary, if an entity has the permission of updating itself without the permission of updating its fields, running the repairer will lead to disabling updating the entity.

It is caused by a change in the way that Group permissions work between QC 9.2 and ALM 11.

The problem could be fixed, by following the below steps:

1. Add the below contents to the following files:

"verify_tasks_deep.xml" and "repair_tasks.xml" under "repository\sa\DomsInfo\MaintenanceData\conf".

For verify_tasks_deep.xml – <ENTRY VALUE="com.mercury.td.saserver.maintenance.verify.EntityUpdatePermissionInconsistencyTask"/>

For repair_tasks.xml – <RepairData class="com.mercury.td.saserver.maintenance.repair.EntityUpdatePermissionInconsistencyRepairer"/>

2. Restart the ALM server.

3. Run the Project Repair Tool.

4. When the migration of the projects is done, remove the lines from the XML files

5. Restart the ALM server

Note: After adding the contents to these files, restarting ALM server, and repairing the project, the greyed out buttons should be enabled.

Note: The above class is disabled (not declared in the list of verifiers/repairers) by default, since it may contain a hidden risk. For example, in the above case, if the "SYSTEM_FIELD.SF_GRANT_MODIFY" is incorrect, the repairer will always align "TABLES.TB_GRANT_MODIFY" to it.

Note: It is very important to remove the lines from the XML files once the repair has finished so other projects are not changed.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s