Question
Wirpo Technologies
AU
Last activity: 7 Oct 2016 11:26 EDT
Assign- Vs Case Type Class in Access Control- GRUN Warranty Case Study
Hi,
I am having little confusion while implementing security to system in GRUN case study. CSR can access own case and case is not submitted(created by otehrs) can open submit. CSR only can create claim case. Claim Processor can pick the case based on skill. Receiving Specilist can collect the product.
I defines 3 main access roles. GRUN:User, GRUN:Processor, GRUN:Receiver
There are three clssed
GRUN-FW-Warranty-Work-Claim
GRUN-FW-Warranty-Work-ProductClaim
GRUN-FW-Warranty-Work-ReceiveProduct
for GRUN:User
1. CanCreateWarranty Priv added and the same added to starter flow.
2. Now for open case is not submitted.
Approach 1: Assign- Level. CanPerform in Assign-Worklist can say below
Hi,
I am having little confusion while implementing security to system in GRUN case study. CSR can access own case and case is not submitted(created by otehrs) can open submit. CSR only can create claim case. Claim Processor can pick the case based on skill. Receiving Specilist can collect the product.
I defines 3 main access roles. GRUN:User, GRUN:Processor, GRUN:Receiver
There are three clssed
GRUN-FW-Warranty-Work-Claim
GRUN-FW-Warranty-Work-ProductClaim
GRUN-FW-Warranty-Work-ReceiveProduct
for GRUN:User
1. CanCreateWarranty Priv added and the same added to starter flow.
2. Now for open case is not submitted.
Approach 1: Assign- Level. CanPerform in Assign-Worklist can say below
Case.Status=="New" && Case.WorkGroup==NewAssignPage. pxWorkGroup
Approach 2: OpenInstance & Modify Instance: CanPerform(Access When): CaseStatus==”New” && WorkGroup of pxCreateOperator==WorkGroup ofCurren User Login
In Both Approach: Case is meant to be GRUN-FW-Warranty-Work-Claim case. Whcih Approch we can use ??.
We have to define GRUN-FW-Warranty-Work-ProductClaim and GRUN-FW-Warranty-Work-ReceiveProduct should not be opened by GRUN:User.
Open Instance and Modify Instance should be true/Production System Setting Level: 5 because GRUN:User has to trigger open/modify case to create child cases(GRUN-FW-Warranty-Work-ProductClaim). But GRUN-FW-Warranty-Work-ReceiveProduct case can set Open/Modify Instance set to 0/false. But child cases(GRUN-FW-Warranty-Work-ProductClaim). Perform Privilege With Value =0/False.
For GRUN:Processor
For Case (GRUN-FW-Warranty-Work-Claim) and Child Case (GRUN-FW-Warranty-Work-ReceiveProduct ) Just set Perform Privilege: 0/false
child cases(GRUN-FW-Warranty-Work-ProductClaim) Perform Privilege to : true/5
For GRUN:Receiver
For Case (GRUN-FW-Warranty-Work-Claim) and Child Case (GRUN-FW-Warranty-Work- ProductClaim) Just set Perform Privilege: 0/false
child cases(GRUN-FW-Warranty-Work-ReceiveProduct) Perform Privilege to : true/5
***Updated by moderator: Maryrita to move from Pega Academy community to PSC***
***Updated by moderator: Marissa to update categories***
Pegasystems Inc.
US
Hello,
I'm not sure I'm following everything you said or what your ultimate question is, but I think your approach of modifying the access when for the class sounds like a solid approach for limiting specific users ability to access the objects. I don't know if you plan to have opperators with multiple roles, but it probably makes more sense to evaluate if they have role XXX:YYY and then give permission (with an else, deny) as opposed to using logic deny permission if the operator has role XXX:YYY. That way a user like a manager, who is allowed to do the work of multiple types of users, don't have any issues.
Thanks,
Mike