SR-B36260 · Issue 296921
Fixed mobile native control submit clearing property/date
Resolved in Pega Version 7.3
When the "native control on mobile" option is checked for a date-time property, a runtime error on submit cleared the property value/date value. To correct this, if the datetime property gets any error messages on submitting the screen, the response of the datetime control will not generate the Value or overwrite it.
SR-B36307 · Issue 292510
prconfig added to disable tracer checks in census
Resolved in Pega Version 7.3
There was some contention when checking for tracer to log trace events for access denials in a census application. Since tracer is not used in census, a prconfig switch has been added to disable these tracer checks.
SR-B36632 · Issue 292416
Improved logic for cloned operators and workpools
Resolved in Pega Version 7.3
The workpools available in a new application were not updating correctly due to a missed use case related to multiple cloned operators and the respective multiple cloned workpools being added to the built-on operator. To better handle this scenario, the following changes have been implemented: 1) If the workpool originally listed on the access group to be cloned derives from a class in the list of classes to be created, then the entry will be updated with the new work pool name. 2) If the workpool originally listed on the access group to be cloned does NOT derive from a class in the list of classes to be created, then the entry will be removed from the new access group. (for example, if the user selected no case types and the old access group had multiple work pools listed, then none of those workpools will be present on the new access group since those work pools were not cloned). 3) If an entry was previously marked as the default work pool, the newly cloned workpool will be marked as the default workpool. (This is a change in logic, as previously the access group always used the default work pool [Org-App-Work]). 4) If the previous default work pool was not cloned to the new application (based on case type selection), then the access group's default workpool will be the first in the list. 5) If there were no work pools present in the list, then the standard Org-App-Work classgroup that is always created as part of the new application process will be added and made the default.
SR-B36632 · Issue 294145
Improved logic for cloned operators and workpools
Resolved in Pega Version 7.3
The workpools available in a new application were not updating correctly due to a missed use case related to multiple cloned operators and the respective multiple cloned workpools being added to the built-on operator. To better handle this scenario, the following changes have been implemented: 1) If the workpool originally listed on the access group to be cloned derives from a class in the list of classes to be created, then the entry will be updated with the new work pool name. 2) If the workpool originally listed on the access group to be cloned does NOT derive from a class in the list of classes to be created, then the entry will be removed from the new access group. (for example, if the user selected no case types and the old access group had multiple work pools listed, then none of those workpools will be present on the new access group since those work pools were not cloned). 3) If an entry was previously marked as the default work pool, the newly cloned workpool will be marked as the default workpool. (This is a change in logic, as previously the access group always used the default work pool [Org-App-Work]). 4) If the previous default work pool was not cloned to the new application (based on case type selection), then the access group's default workpool will be the first in the list. 5) If there were no work pools present in the list, then the standard Org-App-Work classgroup that is always created as part of the new application process will be added and made the default.
SR-B36948 · Issue 296463
Dynamic UI supports repeating grid sourced from Page List
Resolved in Pega Version 7.3
After creating and running a case, clicking on the "Edit Details" option from Other Actions Menu did not display the section containing a repeating grid sourced from a Page List. This was due to the final rule activity "pzdynamicuisetupfields" not considering the case of Page List while configuring the dynamic UI, and it has been updated to properly propagate the values.
SR-B36948 · Issue 298094
Dynamic UI supports repeating grid sourced from Page List
Resolved in Pega Version 7.3
After creating and running a case, clicking on the "Edit Details" option from Other Actions Menu did not display the section containing a repeating grid sourced from a Page List. This was due to the final rule activity "pzdynamicuisetupfields" not considering the case of Page List while configuring the dynamic UI, and it has been updated to properly propagate the values.
SR-B37115 · Issue 293959
PegaUnits bulk testing updated
Resolved in Pega Version 7.3
AUT test cases were failing while running in bulk, though running a single unit worked as expected. This was found to be a conflict with the way a test case uses a current parameter page from the start of execution to end of execution and then passes it to the next test; if there are two data page test cases where one is configured to have a non-blank value for a given parameter while the second one has a blank value for same parameter, the second test unexpectedly encounters the non-blank value. To resolve this, the code has been modified to reset the value of only RUT params before set up is called, so that every test case behaves truly independently.
SR-B37115 · Issue 286705
PegaUnits bulk testing updated
Resolved in Pega Version 7.3
AUT test cases were failing while running in bulk, though running a single unit worked as expected. This was found to be a conflict with the way a test case uses a current parameter page from the start of execution to end of execution and then passes it to the next test; if there are two data page test cases where one is configured to have a non-blank value for a given parameter while the second one has a blank value for same parameter, the second test unexpectedly encounters the non-blank value. To resolve this, the code has been modified to reset the value of only RUT params before set up is called, so that every test case behaves truly independently.
SR-B38034 · Issue 297014
Improved error handling for Usage Daemon
Resolved in Pega Version 7.3
The Usage daemon was exiting due to DB error and did not recover, leading to PALSnapshotImpl multiplying and causing an OOM. This was traced to missing error handling, and UsageDaemon has now been updated to handle a DB error without exiting.
SR-B38157 · Issue 301486
Added post-upgrade compatibility for agent tracing
Resolved in Pega Version 7.3
After upgrade, tracing agents was not working due to a change between versions in the method of tracing rules in rulesets of a remote requestor. Previously, rules were traced in the rulesets of the current requestor who initiated the trace; in newer versions, rulesets are fetched for batch requestors so all rules in rulesets accessible to browser requestor are not traced. In order to resolve this, a traceAllRulesets flag has been added for agent tracing so that all rulesets are traced and a note has been added to the settings window stating that in case of agents, all rulesets are traced.