Want to Customize Access Deny Error Message
Regarding the customization of OOTB message rules, my client would like to make the Database-Authorization-NoOpenAccess rule more user friendly:
Instead of full pzInsKey + flow in the error message displayed to users:
"You are not authorized to open ASSIGN-WORKLIST CIBC-RETBNK-CMPS-WORK-NACS ON-15031300275!CUSTOMERSURVEY"
they would just like to see the relevant information (Case ID only):
"You are not authorized to open ON-15031300275"
Unfortunately the calling activities / methods that set the 'Handle' parameter in this rule are final. This error message can commonly be seen as security has been applied to restrict access only to certain tasks. Is there another suggestion for replacing the Handle parameter with the Case ID?
Message was edited by: Kip Jackson Removed Internal Mesh and SR references.
***Updated by moderator: Lochan to close post***
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
Accepted Solution
Pegasystems
CA
Workaround: There is an OOTB param.key which contains the task pzInsKey. A custom activity was created which retrieves the pxRefInsKey through an Obj-Browse step, which is then used to overwrite the Param.errorMessage value. This custom activity is called by the OOTB PreDisplayHarness template activity, which will only execute if Param.harnessName == "NoID" AND the Param.errorMessage is the specific one that needs to be overwritten.
Pegasystems Inc.
US
Andrew,
My understanding is that this is a fairly big, low level hammer you're looking to change. I would be wary of the repercussions of the sorts of changes you propose (setting aside the fact it would require modifying final rules for the moment). Anything that calls Database-Authorization-NoOpenAccess would end up calling your version, which may or may not make sense. Of course of you reuse the prefix "ON-" in multiple workpools, your message won't clearly identify which item you failed to open. Lastly, customizing this will occlude any changes we make out of the box in the future. And of course, as you point out, you would need to modify final rules.
I would ask you to take a step back. Can the security you've applied be checked elsewhere and leave this message for the error of last resort? Generally, I would question a design that allows users to regularly try and open items only to have them fail. Where are they opening these items from? A worklist? You should be able to add filters to not include the items in question. Are you searching for the item? I'd customize that and capture it up front to either not include it in a search result or to include it in such a way that it's clear you aren't authorized to open it.
Thanks,
Mike
Pegasystems
CA
Hi Mike,
Thanks for the detailed and well-thought out response. I agree with the potential implications of rewording the error message display, and there had been consensus that although more work would be needed by the technical team to troubleshoot (if class details were excluded from the error msg), this could be accomodated (perhaps by storing the handle as a hidden value). The finality of the rule was also a concern, but because the rule is of type message, it was considered as low risk to modify / request for unlocking.
Regarding the security implementation, the application users have the ability to access tasks of all types through the Case Manager portal view, where one can drill down by workgroup and individual workbasket / worklist. It was decided that checking security on access of the task was more efficient then checking during the rendering of the workbasket / worklist, due to the high number of tasks.
I will take the feedback and see if the client is ok with leaving as is.
Thanks,
Andrew
BNY Mellon
US
Good question, but a better question is whether you might want to override the sections here, so that you can simply supply your own error message.
See also Standard for User Error Messages?
Pegasystems
CA
Client is still requesting to see if any workarounds can be done to accomodate their request for a better end user experience. Some research has been done to determine if the wording can be modified, but the use of many final rules has limited the determination of a solution:
Harness @baseclass.NoID
Harness Assign-.NoID
HTML @baseclass.NoID (final)
HTML Assign-.NoID (final)
Section @baseclass.NoID
Section Assign-.NoID
Message Database-Authorization-NoOpenAccess
- contains handle parameter (task pzInsKey)
- called by Work-.WorkLock (final)
Security unfortunately prevents the persistence of assignment data on the clipboard, so the only other option is the handle parameter, which must be parsed in a custom activity (called be a pxLocalAction section) and will not always be in a consistent format. Has anyone had success with alternative solutions?
Accepted Solution
Pegasystems
CA
Workaround: There is an OOTB param.key which contains the task pzInsKey. A custom activity was created which retrieves the pxRefInsKey through an Obj-Browse step, which is then used to overwrite the Param.errorMessage value. This custom activity is called by the OOTB PreDisplayHarness template activity, which will only execute if Param.harnessName == "NoID" AND the Param.errorMessage is the specific one that needs to be overwritten.