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.
This PDN article relates to email@example.com 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
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.
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.
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