Posted: 22 May 2018 7:37 EDT Last activity: 5 Jul 2018 14:06 EDT
Maker-Checker Mechanism on Operator Update
I need to develop maker-checker mechanism on operator updating process. Admin users can change other's access group, workbasket etc. without approval. On operator update screen we try to change page but sections are unchangeable, they are Final. How can I build maker-checker mechanism on operator updating process for Admin users?
***Edited by Moderator Marissa to add SR Details***
For those who may be unaware of the terminology: Maker-checker (or Maker and Checker, or 4-Eyes) is one of the central principles of authorization in the Information Systems of financial organizations.The principle of maker and checker means that for each transaction, there must be at least two individuals necessary for its completion. (from Wiki)
I'm thinking that you might want to modify the "Save" flow for these records (e.g. operator ID) to mimic the process that can be in place for ruleset modifications. From a Ruleset ruleform you see:
Perhaps you can do something similar, not for a ruleset, but for these Operator records; that is, create a flow to use for the approval process? I see this from the help on managing the rule checking process:
You should restrict access to Admistrator@pega.com to only the most trust administrators. It's much like root access on a Unix system. That isn't the operator that anyone should be doing standard operations with. I agree with Ron, that front ending the change with your own rules should allow you to build in whatever level of validation you require. If you want something that applies to Admistrator@pega.com, you should clearly outline the behavior you want in as much detail as possible so that we can get it to the product owners to consider for a future enhancement to the product. That clearly won't get you want you want for today, so you'll still likely need to customize the application to get what you need in your current system.