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.
SR-117877 · Issue 178627
Report on implementation classes corrected for descendant class
Resolved in Pega Version 7.1.8
Report definition was not using implementation class even when 'report on descendant class' was checked. This was caused by an access group changed in RAQ not being reflected into DAQ. When a Data-Admin-Requestor has a Access group which isn't the default, the default authentication doesn't occur and as such the application data page isn't created for the requestor. The lack of an application page causes the code to not determine the associated implementation class for the report definition. This has been changed to use the access group from DAQ only if it is newer than RAQ.
SR-117877 · Issue 175972
Report on implementation classes corrected for descendant class
Resolved in Pega Version 7.1.8
Report definition was not using implementation class even when 'report on descendant class' was checked. This was caused by an access group changed in RAQ not being reflected into DAQ. When a Data-Admin-Requestor has a Access group which isn't the default, the default authentication doesn't occur and as such the application data page isn't created for the requestor. The lack of an application page causes the code to not determine the associated implementation class for the report definition. This has been changed to use the access group from DAQ only if it is newer than RAQ.
SR-118224 · Issue 182305
Report Definition "Pick Value" list resolves to correct layer
Resolved in Pega Version 7.1.8
When a report definition in the framework layer has "Report on descendant class instances" checked, running the report from the implementation layer should retrieve pick list values for "Available Values" on filter popup from the implementation layer. Instead, it was getting the values from the framework layer. This was caused by the code that generates the SQL query to populate the "Pick Value" list resolving to the wrong work class name, using the framework layer work class rather than the implementation layer work class. There was a workaround of performing a 'Save As' of the affected reports to each implementation layer, but this has been fixed.
SR-118224 · Issue 182203
Report Definition "Pick Value" list resolves to correct layer
Resolved in Pega Version 7.1.8
When a report definition in the framework layer has "Report on descendant class instances" checked, running the report from the implementation layer should retrieve pick list values for "Available Values" on filter popup from the implementation layer. Instead, it was getting the values from the framework layer. This was caused by the code that generates the SQL query to populate the "Pick Value" list resolving to the wrong work class name, using the framework layer work class rather than the implementation layer work class. There was a workaround of performing a 'Save As' of the affected reports to each implementation layer, but this has been fixed.
SR-119715 · Issue 178060
Corrected Microsoft Internet Explorer horizontal scroll bar access within large list views
Resolved in Pega Version 7.1.8
If the data present in the list view is huge (2000+ characters), selecting the filter option caused the horizontal scrollbar to not be visible in Internet Explorer. As a result, the apply button was not accessible. This was caused by a lack of overflow settings to handle the excessive width for that browser, and has been fixed.