SR-B3633 · Issue 274006
Tab layout focus corrected for "show next error"
Resolved in Pega Version 7.3
The "Show Error" and "Show Next Error" functionality in the layout group of type tab were not giving focus to the correct element when clicking the 'show next error' if an autocomplete was present. Instead, focus was given to the element whose CSS property display was set to none. To correct this, an additional filter condition has been added to ensure the expected focus.
SR-B36418 · Issue 293162
More descriptive error message for RAP import
Resolved in Pega Version 7.3
In order to clarify that Schema migration does not support importing a table with the same name as an existing view or a view with the same name as an existing table, the code has been updated to throw a more descriptive exception.
SR-B36431 · Issue 293350
SOAP simulations restored
Resolved in Pega Version 7.3
SOAP simulations were not executed as expected due to the hard coded value SOAP being removed and made generic. This has been fixed by updating the service type to SOAP in the parameters passed to the simulations section.
SR-B36556 · Issue 301271
Internet Explorer text input focus fixed
Resolved in Pega Version 7.3
In IE, the mouse could not be used to return focus to a text field once there was text input followed by other clicks around the screen. This was traced to a grid inside the modal dialog launched by a button with an incorrect div that led to the text box losing editability. To resolve this, a check has been added.
SR-B36567 · Issue 296311
Full year date data made available to Excel for consistency
Resolved in Pega Version 7.3
Inconsistencies were seen in the handling of the year field on dates using Date or pxDateTime as a control, at times displaying the same input as 01/01/1917, 01/01/17, and 01/01/2017. To fix this, the date format in pzExport_Date_RD control has been modified from DEFAULT_DATE_SHORT to DEFAULT_DATE_SHORT_YYYY so the full year component is available for Excel.
SR-B3657 · Issue 274527
SAML authentication enhanced to detect encoded/decoded response
Resolved in Pega Version 7.3
Even though SAML authentication was working as expected, an error message was being logged when the system attempted to process the authentication response as encoded before falling back to process it as decoded. To remove confusion, Fallback has been removed and instead the system will intelligently identify the response as encoded/decoded and handle it appropriately without generating an unnecessary error.
SR-B3657 · Issue 280763
SAML authentication enhanced to detect encoded/decoded response
Resolved in Pega Version 7.3
Even though SAML authentication was working as expected, an error message was being logged when the system attempted to process the authentication response as encoded before falling back to process it as decoded. To remove confusion, Fallback has been removed and instead the system will intelligently identify the response as encoded/decoded and handle it appropriately without generating an unnecessary error.
SR-B3657 · Issue 285983
SAML authentication enhanced to detect encoded/decoded response
Resolved in Pega Version 7.3
Even though SAML authentication was working as expected, an error message was being logged when the system attempted to process the authentication response as encoded before falling back to process it as decoded. To remove confusion, Fallback has been removed and instead the system will intelligently identify the response as encoded/decoded and handle it appropriately without generating an unnecessary error.
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.