SR-D71408 · Issue 534934
DIrty check flag triggered by adding columns and filters
Resolved in Pega Version 8.5
If a report was edited and closed without saving, the dirty check worked as expected. However, if new columns or filters were added and the report closed without saving, the dirty check did not appear. This has been resolved by updating the check logic.
SR-D86864 · Issue 548093
Very long auto-generated index trimmed for use in Report Browser
Resolved in Pega Version 8.5
The creation of a new report via the user report browser failed if there was an index with a long name (over 30 characters). The OOTB method automatically generated the prefix, but the Report editor could not handle the very long declare index name and as a result did not consider properties from the embedded pages. To resolve this, pzUpdateAssociation and pzInsertNewReportColumn have been updated to trim the prefix for the declare index to 30 characters and allow for adding a new column to the report. This work does not cover adding a new filter to the report, as that fix would require substantial changes to reporting logic.
SR-D53176 · Issue 541795
Error when adding function filter will persist
Resolved in Pega Version 8.5
When an exception occurred while adding a filter in the report viewer, the error was shown but cleared due to an immediate refresh of the parent section. Analysis found that step2 of pzGetFiltersFromContent was failing, after which the error was shown, the section reload happened, and the error disappeared. To resolve the error being cleared prematurely, the pzOnLoadReloadReport control has been modified so that when there are messages on the top level page (pyReportContentPage), a parameter will be set on HarnessContextMgr to not to clear them during the next refresh call.
SR-D73777 · Issue 539969
Logic added for client-side Somaria decoding
Resolved in Pega Version 8.5
When Somaria (an Advanced Data Visualization control) was used with Predictor Performance, the special characters were displayed as ASCII values instead of the actual values in the label. This was traced to Somaria encoding special characters of the visualization data into HTML entities on the server in order to protect against cross-site scripting attacks, but these entities were not being decoded on the client side. To resolve this, logic has been added to decode HTML entities in Somaria data on the client.
SR-D80589 · Issue 544841
Check added before clearing Report definition custom filter section page
Resolved in Pega Version 8.5
When using a Custom Section in the Report Viewer, the Page referred to at the Prefix was getting reset while running the report. Investigation showed the page was being reinitialized in pzCreateCustomFilterPage step 2, and this has been resolved by adding a 'when' rule for clearing the custom filter page.
SR-D81496 · Issue 547170
Data Social tag class FTS index query improvements
Resolved in Pega Version 8.5
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.
INC-134046 · Issue 575238
database locking improved for login performance
Resolved in Pega Version 8.5
A slowness issue seen when trying to login to my.pega.com was traced to numerous database locks occurring on the pr_data_saml_authreqcontext table during the SAML flow. Analysis showed that while running Obj-Save on AuthRequestContext with 'OnlyIfNew' as false, the check caused a select query to run on the table to determine if the context was already there and insert it if it was not. To resolve this, the onlyIfNew check will default to true to avoid running the query; if the context is already present it will be overridden. Duplicate key exception handling has also been added to avoid any issues if a resave is done with same key.
SR-D96395 · Issue 555118
CDK key loading modified for better database compatibility
Resolved in Pega Version 8.5
Users were unable to log on to the system and received the error "There has been an issue; please consult your system administrator." Investigation showed the log errors stating "(dataencryption.DataKeyProvider) ERROR localhost - Could not get CDK from systemKeyManagementCache - System CDK is null". This was an issue specific to the MS SQL Server database when there were 6 or more CDKs in the database: CDK keys are loaded from database into Cache using an SQL statement which had the ORDER clause. By default, the ORDER clause treats NULL values differently on different databases, and this caused MS SQL databases to not load a necessary CDK key. To resolve this, the SQL query has been modified so the result will be the same for all supported daatbases (Oracle, Postgres & MS SQL Server).
INC-132209 · Issue 577000
CDK key loading modified for better database compatibility
Resolved in Pega Version 8.5
Users were unable to log on to the system and received the error "There has been an issue; please consult your system administrator." Investigation showed the log errors stating "(dataencryption.DataKeyProvider) ERROR localhost - Could not get CDK from systemKeyManagementCache - System CDK is null". This was an issue specific to the MS SQL Server database when there were 6 or more CDKs in the database: CDK keys are loaded from database into Cache using an SQL statement which had the ORDER clause. By default, the ORDER clause treats NULL values differently on different databases, and this caused MS SQL databases to not load a necessary CDK key. To resolve this, the SQL query has been modified so the result will be the same for all supported daatbases (Oracle, Postgres & MS SQL Server).
INC-118927 · Issue 571491
Resolved OAuth2 mobile app loop
Resolved in Pega Version 8.5
When a Pega OAuth2 authorize endpoint was invoked and the redirect URI contained "app", a loop was created where the system attempted to fetch the app alias from the state parameter value and was redirected back to itself. This could sometimes result in inconsistent mobile app styling. Investigation showed that a certificate with keyword app that was picked for the redirect URI could have the key word assumed to be the app alias context, so a workaround was to remove the app keyword. To resolve the issue, the system has been updated to look for the app alias only in the state parameter rather than performa a string contains check on the entire query string.