In ALM 11.00 and above, you can experience the below issue in a project upgraded from QC 10.00, or a project newly created in ALM 11.00.
1.Manifestations of the problem:
a. In Customization->Groups and Permissions, group G is permitted to update field F in entity E but I cannot update this field.
b. In Customization->Groups and Permissions, group G is permitted to update entity E but I cannot update it.
c. In Customization->Groups and Permissions, group G is permitted to update entity E but I cannot copy-paste it.
d. Or any other similar manifestations saying Customization allows update but update is prevented in work in the modules themselves.
2. In ALM (11.00 and above) permission model, once a group G has at least the update permission of a field F of a entity E, ALM should regard the update permission of E is also granted to G .
However for some upgraded projects or new projects, by default we have the group G with the update permission of a field F but without the update permission of its parent entity E.
This is what we call “Inconsistent Permission”.
3. Look in the Customization->Groups and Permissions UI to make sure that it is actually permitted to update entity E. After that, the below SQL can help to identify any permission inconsistency on a specific table.
Replace ‘<E>’ with the entity table name, and run this SQL in site admin, then if there’s any inconsistency on the entity permission, the current permission (TB_GRANT_MODIFY) and the correct permission (CORRECT_PERMISSION) will be listed.
SELECT TB_TABLE_NAME, TB_GRANT_MODIFY, SF_GRANT_MODIFY AS CORRECT_PERMISSION FROM TABLES INNER JOIN SYSTEM_FIELD ON TB_TABLE_NAME=SF_TABLE_NAME AND SF_CAN_CHANGE_PERMISSIONS=’Y’ AND (SF_IS_SYSTEM=’Y’ OR SF_IS_ACTIVE=’Y’) AND TB_GRANT_MODIFY<SF_GRANT_MODIFY AND TB_TABLE_NAME=’<E>’
In this case, the solution below might be relevant.
The fix for this problem is contained in ALM 11 and ALM 11.5 patches.
The fix uses a verifier and repairer that find inconsistencies for the given tables and fix them by allowing entity update where it finds the update of at least one of their fields is permitted.
Note: the fix will always change the entity update permission from no to yes. So prior to use it, please make sure you really want to grant the entity update permission to this group.
In order to use this fix, we need to:
Upgrade patch level:
· In ALM 11, upgrade the patch level to at least patch 14.
· In ALM 11.5 and further, upgrade the version to at least ALM 11.52 patch 1.
Instructions for ALM 11 patch 14 or later and for ALM 11.52 patch 1 or later :
1. Backup your projects.
2. Add the required site parameter – Add a site parameter named “ENTITY_TABLE_NAMES_FOR_FIXING_UPDATE_PERMISSIONS_INCONSISTENCY”. The value of this parameter should be a comma separated list of the entity table names corresponding to the entities for which a problem was found in the TABLES table. For example: “BUG,REQ”.
3. Repair all relevant projects – This will update the TABLES table to fix the inconsistencies that were found.
Note: it’s possible to run “Repair” on a domain level – a one-click operation for all the projects in a domain.
4. Return server to original state – Delete the site parameter added in step 2.
Note: You MUST return server to original state prior to project upgrade, otherwise some side effect will take place during the project upgrade and will cause the upgraded project to be unstable.
5. Once done, the problem should be fixed – Run the SQL above to see that no consistency exists for those entities and check the functionality itself to see that the issue was fixed.