SR-B3591 · Issue 277488
Unit Test Case for DataPage localized for comma decimal indicators
Resolved in Pega Version 7.3
When using Dutch language localization, the use of a comma in a decimal number caused a parsing error when creating a Unit Test Case for a DataPage. Proper handling has been added to handle this localization format.
SR-B3591 · Issue 278006
Unit Test Case for DataPage localized for comma decimal indicators
Resolved in Pega Version 7.3
When using Dutch language localization, the use of a comma in a decimal number caused a parsing error when creating a Unit Test Case for a DataPage. Proper handling has been added to handle this localization format.
SR-B35987 · Issue 296514
Improved backwards compatibility for migrated rules with Declare Expressions
Resolved in Pega Version 7.3
The current activity pzUpdateConditionsList did not have backward compatibility for "AND" and "OR" operators in rules created with older version of Pega Platform that allowed the use of "And" and "Or". This has been resolved by adding a check for equalsIgnoreCase when converting "And" to "&&".
SR-B36091 · Issue 292431
Hazelcast logging added with updated jar
Resolved in Pega Version 7.3
Additional Hazelcast logging has been added and and the prcluster-7.1.jar has been rebuilt for better reliability.
SR-B36134 · Issue 294001
Security fix to prevent URL tampering
Resolved in Pega Version 7.3
Pasting a URL that corresponds to an activity to invoke express on the browser URL allowed end users to get the express experience. To secure the system, the portal switching logic has been hardened to reinforce a portal check against access group privileges and to allow for equivalencies.
SR-B36134 · Issue 294080
Security fix to prevent URL tampering
Resolved in Pega Version 7.3
Pasting a URL that corresponds to an activity to invoke express on the browser URL allowed end users to get the express experience. To secure the system, the portal switching logic has been hardened to reinforce a portal check against access group privileges and to allow for equivalencies.
SR-B36228 · Issue 292442
Improved RuntimeCacheImpl performance
Resolved in Pega Version 7.3
There was unnecessary contention within the RuntimeCacheImpl when that class was asked to provide information about a blank class name. To correct this and improve performance, a check for the empty class name has been moved out of the synchronized block to the top of this method.
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.