Why can't an administrator update an OperatorID rule once the user has signed on?
In 7.1.8 once a user has signed in it seems no one can update their OperatorID rule; when opening the rule the message "You are not authorized to create, modify, or lock instance DATA-ADMIN-OPERATOR-ID xxxxxxxx". In 7.1.7 - and all previous version of PRPC - a user with the PegaRULES:SysAdmin4 Role could update OperatorID Rules; eg. change the AccessGroup.
Does anyone know how to overcome this issue?
Accepted Solution
Pegasystems Inc.
GB
I eventually managed to resolve the issue. It seems that when the new Application was generated the RARO rule generated for the Data-Admin-Operator-ID didn't give the user access to update their own OperatorID rule!! Consequently, as soon as the user signed in the rule was flagged as in error (pyRuleFormStatus set to "Error") and then no-one could update it.
Pegasystems Inc.
JP
see pdn support article https://community.pega.com/support/support-articles/unable-change-password-administratorpegacom
Pegasystems Inc.
GB
This PDN article relates to [email protected] updating its own password. The issue we have in 7.1.8 is a user with a SysAdmin4 Role cannot update another users OperatorID rule once that user has signed on. A system administrator must be able to update the OperatorID rule when a user's AccessGroup, WorkBasket(s), Skill(s) etc. change
Try adding PegaRULES:SysAdm5. It should allow. Else clone SysAdm4 role and make sure that write instances setting on Data-Admin-Operator-ID is 5 or something appropriate for your environment
Pegasystems Inc.
GB
I've already tried what you suggest. However, PegaRULES:SysAdm5 has now been Withdrawn (in the earlier Ruleset Version it didn't contain anything). I've tried to replicate on my Personal Edition 7.1.9 and it seems to work ok there. I'll do an import from the system 7.1.8 an see what happens.
Accepted Solution
Pegasystems Inc.
GB
I eventually managed to resolve the issue. It seems that when the new Application was generated the RARO rule generated for the Data-Admin-Operator-ID didn't give the user access to update their own OperatorID rule!! Consequently, as soon as the user signed in the rule was flagged as in error (pyRuleFormStatus set to "Error") and then no-one could update it.
Updated: 9 Nov 2015 4:46 EST
Pegasystems Inc.
JP
In other words, a non-admin user should not be allowed to change any field of its own operator id record except password.
Pegasystems Inc.
GB
In terms of what the user can actually do themselves you're correct. However, when the user signs in the "pyLastSignon" property, and maybe some others, is updated and the rule saved, so the user must have the security to do this. Also, for some clients we need to "extend" the Data-Admin-Operator-ID class by adding additional Properties to store some "preferences" etc. eg. filter values saved from a previous session