Short Description
In this document, you will learn about the following topics:
- Dirty dialog
- Difference between a browser Dirty Dialog and Pega Dirty Dialog
- When to use the browser Dirty and Pega Dirty Dialog
- Disabling the Dirty Dialog warnings/pop up
- Use of pega.u.d.gDirtyOverride function
- Use of pega.u.discardHandler function
- Dirty Dialog in Frameless Portal
- Discard Handler incase of Parallel Processing
- Dirty Dialog in Constellation
What is Dirty Dialog?
Dirty forms appear when a user makes changes in the current rule, and then tries to navigate away or close that rule without saving the data.
Browser Dirty Dialog v/s Pega Dirty Dialog
By default, Pega provides the Pega dirty dialog.
However, for browser popup, use the following script in the in UserWorkForm.
<script>
pega.u.d.bUseNativeDirtyConfirm = true;
</script>
When to use the Browser Dirty vs Pega Dirty Dialog
It is recommended to use the Pega Dirty dialog only instead of the browser dirty popup. However, if the customer wants to use the browser dirty popup, we can set pega.u.d.bUseNativeDirtyConfirm = true;
in the UserWorkForm.
Disable the Dirty Dialog warnings/pop up
- To disable the dirty check at the harness level, enable the Do not disable dirty warnings checkbox in the Harness Advanced configuration.
- To disable the dirty check in a particular section, embed the OOTB section rule
@baseclass.pxDisableClientDirtyDetection
in the section. - To disable the dirty check in a certain scenario on a particular field, enable the post value.
- To disable the dirty check on a button, use the Click event, perform a Run script action, and call the below function.
<script>
function clearDirty(){
pega.u.d.clearDirtyState();
}
</script>
Scenarios
Scenario 1: Dirty Form does not show the dirty popup as expected
Root cause 1: Check if the Dirty Warnings are enabled for the UI screen. Check if the Do not disable dirty warnings checkbox is enabled in the Harness' Advanced configuration.
Solution: Uncheck Do not disable dirty warnings checkbox in the Harness Advanced configuration.
Root cause 2: Check the actions configured on the Property field for which the actions are mentioned.
- Post Value
- Refresh Section
The Post Value and the Refresh Section are commonly used action set on properties. As and when these actions are used at the input control level, on moving out of the property, the values are posted in the clipboard.
According to the Pega Product, once values are posted to the clipboard, they are no longer dirty and there is no way to check if the values have changed.
By default, the section will be dirty and moving away from the screen will show the dirty dialog. Remove these actions (Post Value or Refresh Section) from the Property field to confirm the scenario.
Solution: Remove these actions (Post Value or Refresh Section) from the Property field and then observe the behavior. If this works, refer to Configuring confirmation modal dialog boxes to make this configuration work.
For more information, refer to Configuring confirmation modal dialog boxes
Root Cause 3: Check the Document Type. The behavior changes according to the document type.
Solution:
- Multi Document (Case manager): Typically, the Case Manager portal uses a multi document dynamic container. So, when you have an open case with a dirty form and you click on any left navigation item, you are not taken away from your case. It is still in the DOM, and when you click on that Case ID from the Recents tab section, it will switch right back with your form data intact.
- Single Page Document (Case Worker): The Case worker portal uses the Single document dynamic container. The portal will show a dirty popup, on navigating away from the work object. If the portal does not display the dirty popup, refer to the above scenarios.
- Ajax Container (Theme Cosmos): Ajax Container will show a dirty popup, on navigating away from the work object. If the Ajax Container does not display the dirty popup, refer to the above scenarios.
Scenario 2: Form is not Dirty but the dirty popup displays
This can be a Product Bug. Reach out to GCS via an Incident for help.
Scenario 3: Launch Local action and Dirty Popup displays, but on clicking the button in the dirty dialog, user is not directed to the required screen
Root cause: Check if the Layouts used are deprecated.
Solution: Upgrade to the latest layouts.
Scenario 3.1: Discard/Ok (Event: Cancel) is not working
Root cause: Check if the Pega Dirty Dialog is used.
Solution:
If yes, use the browser level Dirty Dialog, which provides the OK button. To use the browser level dirty dialog, use the following script.
<script>
pega.u.d.bUseNativeDirtyConfirm = true;
</script>
Or
Check the action configured on the OK or Discard buttons. The action should be pega.u.d.discardHandler
function.
If no, then check the isformDirty function, as this controls the display of the modal dialog.
Scenario 3.2: Save is not working
Root cause: Check if the Pega Dirty Dialog is used.
Solution: If yes, we may need to use the browser level Dirty Dialog, which does not support the Save operation.
To use the browser level dirty dialog, use the following script.
<script>
pega.u.d.bUseNativeDirtyConfirm = true;
</script>
Scenario 4: Form is Dirty and dirty dialog displays; however the dirty dialog is not needed
Refer to Disable the Dirty Dialog warnings/pop up
Use of pega.u.d.gDirtyOverridefunction
If customer does not want to display dirty popup, this flag can be used alternatively. Upon setting this flag to false, the dirty popup will not display.
Use of pega.u.discardHandler function
Upon performing any action, if the dirty popup displays and the user clicks the OK or the Discard button, ideally the action which caused the dirty popup should be executed. For achieving this functionality, the pega.u.d.discardHandler
function is used. This is configured for the OK or Discard buttons.
Possible issue when using the pega.u.d.discardHandler
API
On click of the OK or Discard buttons, if the work object is closed instead of performing earlier actions, check if the pega.u.d.discardHandler
function is configured in the runScript
action upon Click event.
Dirty Dialog in Frameless Portal
In Frameless portals (neither Case Manager nor case worker), the dirty popup will not work in all the use cases. This is currently being worked as an enhancement.
To enable the confirmation dialog boxes for frameless portals with work items that include Post value or Refresh local actions, set the following script:
<script>
pega.u.d.handleDirtyForFramelessPortals = true;
</script>
Along with setting the above mentioned flag to true, we must also set the below script in a function, and this function must be called in the runscript
action upon Change event in the control which is configured with Refresh Section or Post Value actions.
<script>
pega.ctx.ignoreDirtyState = false;
</script>
Discard Handler incase of Parallel Processing
The dirty popup appears when a user edits a field in the form or tries to edit a field with the Post-value/Refresh section configured. In both cases, displaying the dirty pop-up is a valid use case.
In the scenario of a local action, as the same thread is present throughout the processing, discard launches the local action. When navigating back to the previous screen, the UI is updated with clipboard data. However, in the case of a parallel process that uses an open assignment, a thread is opened and closed each time, leading to values not being maintained at the thread level.
Dirty Dialog in Constellation
In the Constellation, only Browser Dirty Popup will be shown. There are two types of dirty dialogs as below,
- When the case is created: On cancel, this triggers a
CancelALERT
API. - During the work object processing within the work object: In this, only the browser level dirty popup will be displayed.