Operator Skill maintenance issue after upgrade from 5.4 to v7
We have recently upgraded from PRPC 5.4 to v7.1.9.
In 5.4 the Operator IDs had skills embedded in pagelist pySkills as instances of Data-Admin-Skill whereas in v7 the page class is Embed-Data-Admin-Skill. In terms of validation also there is a significant different in 5.4 it was possible to add skills in the operator profile which are not defined in the system as Skill rules (say it was possible to type xyz and save the OperatorID), whereas in 7.1 there is a validation in place to check for the existence of the Skill rules (within the same application) and duplicates.
We have the following issues at hand now
1. Many existing Skills in OperatorIDs are rules that existed in a rule set belonging to a different application (we have four Application instances in production).
2. Many existing Skills in OperatorIDs doesn’t have any rule created at all (owing to the lack of any strict validation in 5.4)
To address these, the following options getting considered/
- Suppress the validations which are there OOTB by overriding the validation logic (customization).
- Create/Recreate skills to ensure visibility – Move existing skill definitions to a common rule set visible for all Applications and define those which doesn’t exist in the system.
Inviting suggestions/thoughts on this, and specifically from anyone who had encountered this and addressed the same.
We have recently upgraded from PRPC 5.4 to v7.1.9.
In 5.4 the Operator IDs had skills embedded in pagelist pySkills as instances of Data-Admin-Skill whereas in v7 the page class is Embed-Data-Admin-Skill. In terms of validation also there is a significant different in 5.4 it was possible to add skills in the operator profile which are not defined in the system as Skill rules (say it was possible to type xyz and save the OperatorID), whereas in 7.1 there is a validation in place to check for the existence of the Skill rules (within the same application) and duplicates.
We have the following issues at hand now
1. Many existing Skills in OperatorIDs are rules that existed in a rule set belonging to a different application (we have four Application instances in production).
2. Many existing Skills in OperatorIDs doesn’t have any rule created at all (owing to the lack of any strict validation in 5.4)
To address these, the following options getting considered/
- Suppress the validations which are there OOTB by overriding the validation logic (customization).
- Create/Recreate skills to ensure visibility – Move existing skill definitions to a common rule set visible for all Applications and define those which doesn’t exist in the system.
Inviting suggestions/thoughts on this, and specifically from anyone who had encountered this and addressed the same.
***Updated by Moderator: Marissa. Removed user added Ask the Expert & SR Exists group tags. Apologies for confusion, shouldn't have been an end-user option; updated categories***
Accepted Solution
Pegasystems Inc.
US
I agree with Damah, you want to give the operator legitimate access to the skills. As the product matures, validation is often added to places where it becomes clear it should have been and after an upgrade (particularly a large jump like you've done) a bit of work is required if you were on the wrong side of that lack of validation.
Thanks,
Mike
Pegasystems Inc.
IN
Hi,
Probably the 2nd option that you have come up with, is the right solution according to pega architechture of skill rules, though it is little tedious task of recreating all the skill rules, which are not present earlier .
Accepted Solution
Pegasystems Inc.
US
I agree with Damah, you want to give the operator legitimate access to the skills. As the product matures, validation is often added to places where it becomes clear it should have been and after an upgrade (particularly a large jump like you've done) a bit of work is required if you were on the wrong side of that lack of validation.
Thanks,
Mike