SR-D81496 · Issue 547169
Data Social tag class FTS index query improvements
Resolved in Pega Version 8.2.7
A query intended to select from the link tag table to see if any cases were linked to the tag in question and then index the tag change was causing performance issues. Investigation showed that checking tag associations during FTS indexing fetched all matching rows from the table even though one was sufficient. To resolve this, the query will be created with max result count = 1, fetching up to 2 rows from the table.
SR-D88500 · Issue 562655
Eligibility prompt integer values sorted by incremental size
Resolved in Pega Version 8.2.7
In an Offer rule on the Eligibility tab of the Eligibility Builder, an eligibility row using {integer property} comparator {value} had the list of prompt values sorted alphabetically for integer values rather than incremental size when using Select value -> Existing Values. This has been corrected by revising the logic in addValuesToOutputPage to call Report.sort with different sorting algorithm for numeric values. Logic was also updated to call Report.sort for prompt lists.
SR-D90232 · Issue 555780
Combo charts now support conditional colors
Resolved in Pega Version 8.2.7
An enhancement has been added to facilitate the use of conditional colors in combination charts.
SR-D90750 · Issue 549580
Search behavior change after update corrected
Resolved in Pega Version 8.2.7
After update, changes were seen in the search behavior that included the toggle button at the top left corner of the landing page becoming disabled when re-indexing was in process, the Re-index buttons becoming disabled and a cancel button appearing in place of the re-index button for the specific index category being indexed, indexing done through batch indexers not presenting progress in the document size column every 10 seconds but instead presented the whole row for the index category as blank, and progress being indicated by the changing figures under the Queue Information section on the Search Landing Page. This was due to a conflict in which ruleset was highest after rulesets were imported during update, and has been resolved by updating pzLPSearchManagerReIndexSection to use the correct version of the ruleset.
SR-D91038 · Issue 553164
Corrected report with combo chart in Case Manager portal
Resolved in Pega Version 8.2.7
After adding the required columns a report in the report viewer and then adding a combo chart and dropping the summarized column on the y-axes and group by column on X-axis, clicking on "done editing" generated the error "pyUI.pyChart: You must have at least two Aggregate Columns in the chart series .pyUI.pyChart.pyDataAxis(1).pyChartOutputType: A Combo chart requires at least 1 Chart Type be a Column". Investigation showed that the second DataAxis page was getting deleted in the pzCleanChartDataAxis activity, causing the validation to fail. This has been resolved by adding a 'when' rule to "pzChartIsSingleY" that checks for "SingleYAxisClustered" chart and refers the same in pzCleanChartDataAxis to skip the data axis deletion.
SR-D94002 · Issue 553766
Export to Excel cell style control added
Resolved in Pega Version 8.2.7
If a column was formatted with an auto generated numeric control, a new cell style was generated for every row during the export to Excel process. Since there is a limit on the amount of cell styles, once the number of rows in the file was greater than 64000 an error was generated. To resolve this, the system will disable the creation of a new cell style for every instance when an auto-generated numeric control is used.
INC-118838 · Issue 560691
OKTA receives parameters on logout
Resolved in Pega Version 8.2.7
When using an OIDC logout endpoint with a parameter set as a data page value, the data page retrieved the ID Token from the DB, but when logout was clicked the datapage name was being displayed in the browser instead of the IDToken. To resolve this, code has been added to support sending ID token parameters for logoff endpoint for OKTA logoff using OpeniD connect.
SR-D95148 · Issue 557483
Port validation updated for redirect URI
Resolved in Pega Version 8.2.7
When an offline app for windows client was generated, trying to login via SSO resulted in the error "invalid redirect_uri". This was traced to the system validating the whole loopback redirection URL, e.g. "http://127.0.0.1:1234/redirection", including the port number. To enhance flexibility, an update has been made so that the port number will not be validated, allowing the client to establish it based on availability at the moment of the request to the authorization service. NOTE: As a best practice, a loopback URL should not be configured as a redirect URI. If a loopback URL is configured, then at run time the port number will not be validated, and the client application can use any available port on the system including ports that may not be intended for use.
SR-D62754 · Issue 559848
PrepareResponse updated to explictly close Input Handler
Resolved in Pega Version 8.2.7
When using prpcServiceUtils to export a product in a Windows+Weblogic environment, attempting to export repeatedly using the same archiveName with the intention of overwriting the older product with the newer one in the ServiceExport directory failed with a FileNotFoundException. Investigation showed that the product file that was created by the pzExport REST call was not being released by the Weblogic File Handler process. Due to this, the next time the call was invoked the system tried to create the same file in the directory but failed due to the earlier File handle lock. To resolve this, the system has been updated to explicitly close the InputStream using try-with-resources.
SR-D78274 · Issue 544092
Handling added for dual privileges with MSSQL
Resolved in Pega Version 8.2.7
After setting up dual privileges, the Admin user was able to create a table but the base user received an "insufficient privileges" error. Investigation showed this was an issue when using MSSQL: the generated grant statements used the server login name as the user in the grant statement, instead of the database user. For all other databases, the username passed into the connection is the correct user to use for grants. Only MSSQL has a distinction between this connection user name (the login) and the database user, and since the login did not exist in the user table, the grant failed. To resolve this, when MSSQL is used, the system will fetch the underlying database user when determining the user for grant statement generation.