Question
Red Alpha
US
Last activity: 20 Jan 2025 6:16 EST
How do I keep users not assigned to a case from being able to click Go?
Hello folks! My team and I are currently working on an application in which we wish to keep users not explicitly assigned to a particular work item from being able to enter the work item and edit it. Obviously, when a work item is not assigned to an individual it does not show up in their Task list; however, if a user were to search for a particular work item by ID that is not assigned to them they are able to bring up that work item and click "Go" to begin working on it. This behavior seems quite odd to my team and I, and definitely feels like it should be configurable out of the box. I have scoured the case settings for a possible checkbox to lock down cases to only be workable by those assigned to them (either individual operator or specific work group), but have found nothing. I have encountered this lack of case restriction in both Cosmos and Constellation, but I am most curious about a Constellation based solution. Any advice would be much appreciated!
The attached file shows a work item routed to a RequestManagers work group. I am logged in as myself and I am not a member of the RequestManagers work group, but I am still able to enter the work item and make changes to it.
Updated: 9 Jan 2025 0:51 EST
CollabPartnerz
IN
Hi @TessPorter,
What are you trying to achieve, you want to hide work items not in their work list or do you want to display the item but "GO" should be hidden for items that are not in their work list?
Evonsys
IN
This has been a problem in Constellation, we have achieved by adding Access role to Obj to Access Role in the Access groups. Attached the screenshots for better understanding.
Red Alpha
US
@KishoreKumarMadduriHello Kishore, I gave this a try on my end and it resolved parts of the issue, but introduced a new error. On of my workflows starts with a form collection step followed by an approval step. The approval step is routed to a work group. However, after I updating the access roles for the various users involved a permissions error came up preventing submission of the original form. In you implementation did you ever run into an error like this?
Updated: 15 Jan 2025 4:19 EST
Evonsys
IN
Try checking the Workgroup condition in the access when rule and check if it is working. if not provide details or screen snap of the Cascading approval configuration for better understanding.
Red Alpha
US
@KishoreKumarMadduri Hello Kishore, Attached are images of my workflow with the cascading approval. I'm also curious, when you got these access role permissions successfully configured did they make it so the Go button was hidden from users who did not have access, or did it only make it so they could not click the Go button?
Red Alpha, LLC
US
Please see my comment below as to how we were able to resolve the issue by specifying a Role in the Work Queue rule to which the case was assigned. It appears that by default the Roles area of the Work Queue is allowed to be empty, which enables full access to the assignments. Adding a Role makes it so that users must have that role in order to perform the assignments to that Work Queue.
HCA Healthcare
US
@TessPorter To prevent users not assigned to a case from clicking "Go" and working on it in a Pega Constellation application, you can use Access Control Policies and Locking Settings. Create an Access Control Policy of type Read that checks if the current operator is assigned to the case by comparing .pxAssignedOperatorID with OperatorID. Set the Work Item Locking under the case settings to "Allow only one user to work on a case at a time" to restrict simultaneous access. Ensure that cases routed to a work group, such as RequestManagers, are only accessible by members of that group. Additionally, you can modify the Case Summary View by setting visibility conditions on the "Go" button, ensuring it only appears for authorized users. These steps will ensure only assigned users can work on a case, even if someone searches for it manually. Test the setup with users outside the work group to ensure restricted access. This setup improves security and prevents unauthorized case modifications
Red Alpha
US
@Sairohith Hello Sairohith, I am working on trying out this Access Control Policy solution, but I am curious about what you mentioned about setting visibility conditions on the "Go" button. My team and I were able to do this in Cosmos, but not in Constellation. How did you go about setting visibility conditions on the "Go" button in Constellation?
HCA Healthcare
US
@TessPorterIn Constellation, the "Go" button is part of the pre-configured UX that is more locked down compared to Cosmos. However, you can control its visibility using a Custom View Configuration . Thanks
Red Alpha, LLC
US
Hello all - Part of Tess' team here and wanting to reiterate her question but also point out another issue/question. It seems that with Constellation offering a distinct separation between the UI and the backend/business processing, access conditions and permissions are not propagating to the visibility of certain controls. For example, if we remove the Modify permission on the Request case type for a specific Persona, users in that Persona can still see the Quick Create button for that case type in the Self-Service Portal and can still see the Go button when viewing a case of that type, yet clicking on either of these buttons does absolutely nothing. No error or message is displayed to the user, it just simply does nothing. This seems counterintuitive - if a button will not allow action to be taken, why is it even visible?! In Cosmos the button would not display if the action was prohibited. Or are we missing something in a configuration somewhere?
Red Alpha, LLC
US
After further testing and review, we found that the Work Queue that held the assignment "RequestManagers" as shown in Tess' original screenshot did not have an entry in the "Roles" area of the Work Queue. Apparently this means that EVERYONE can access that assignment, even if they don't explicitly have access to the Work Queue.
To correct the issue of the Go button being displayed, we added the REQS:RequestManagersManaged role to the Roles area of the Work Queue. This required the operator to have that REQS:RequestManagersManaged role in order to access the assignment.
We feel this Roles area should be a required field. Without it being required, leaving it empty as it is by default allows universal access to assignments.
Pegasystems Inc.
GB
@JonathanB9941 @TessPorter thanks for the above details.
The documentation Creating a Work Queue does mention the need to fill in this optional configuration.
A cursory checks tells me that past requests to change this default behaviour were denied in the past.
If you're happy that Tess' original issue is resolved, would you be able to mark your reply with 'Accept Solution'?