SR-D88419 · Issue 557945
Corrected date formatting for use as a custom filter
Resolved in Pega Version 8.4.2
Given a Report Definition with custom filter section, when the custom filter section had a date property which was used under filters, the filter was not shown as a date. The date was shown properly when the custom filter section was not used. This was related to the date conversion for the locale, and has been resolved by modifying the RRFilters_Logic to remove a check for dates ending in GMT and replace it with a check whether the report uses a custom filter section. This runs the correct logic to render the date as expected.
INC-127680 · Issue 573012
Extra 'when' check added to visibility of Sort by and Summarize
Resolved in Pega Version 8.4.2
When changing filter and sort options while viewing a report, two edit filter pop-ups displayed. Neither would close, and further changes to filter options were blocked. The tracer showed that the pzDisplaySummarizeAndSortBy 'when' condition was True, allowing the Sort by drop down to be visible, causing pzReportConfigSections to create the two popups which then caused issues during the on change action. To correct this, an additional check has been added to the 'when' rule for the Visibility of Sort by and Summarize by so that it does not show any longer.
SR-B66454 · Issue 316846
Support added for filtering labels in Join
Resolved in Pega Version 7.3.1
When class join was used in a report and the property used for filtering was a SinglePage property of the join class, then the label was not coming up in the Report Filter section. This was due to filtering labels not being shown when Join is used, and support for this has been added.
SR-D93561 · Issue 558675
Report Definition now searches encrypted properties
Resolved in Pega Version 8.4.2
When using a section in table sourced from a report definition where one of the filter condition properties used was an encrypted property, running the report gave the correct result based on the filter condition but running the case and passing the encrypted property as a parameter to search did not produce the correct result. No data was displayed in the table sourced from the report definition. Because the encryption was done on the parameter string but not the value referenced by parameter, when a report definition is used as a data source for a table, the filter applied on an encrypted property is dropped in the final SQL statement that's generated, leading to incomplete or wrong results to the report. This has been resolved by moving the encryption logic to RuntimeResolver.
SR-D89071 · Issue 569733
Case status label localized in export to Excel
Resolved in Pega Version 8.4.2
The Case status(.pyStatusWork) value was not localized in export to Excel. Investigation traced this to Report definitions not passing default parameters specified on the property ruleform for the "default control". Therefore, the first 'when' condition in WorkStatus was evaluating as false, which caused the wrong field value to be used for reports. To resolve this, the first 'when' condition of WorkStatus control has been updated to succeed if the useStatusWorkFieldValue parameter is not passed. The default is true when it is not present.
SR-D98736 · Issue 563546
Report Definition returns ElasticSearch with parameter in the filter
Resolved in Pega Version 8.4.2
When using a parameter reference in the filter of a Report Definition with a datapage sourced by a Report Definition, ElasticSearch did not return any results if the checkbox "use null if empty" was selected for the filter, but unchecking this checkbox caused a severe warning. Investigation showed that when the checkbox was selected and there was no default value provided for the parameter in the Report Definition, the query formed had no check for a parameter value and the value in the datapage was ignored. This was traced to the operator in the Report Definition filter being overridden during the Report Definition save with the operator type changing from EQUALTO to ISNULL. This has been resolved by adding code changes to verify whether the Report Definition is in validation mode before applying changes.
INC-119669 · Issue 562589
Special character handling added to filters for table sourced with parameterized Report Definition
Resolved in Pega Version 8.4.2
Filters were not working on a table when sourced with a report definition which accepted a parameter value containing special characters (Eg: S&P). This has been resolved by using StringUtils.reversibleCrossScriptingFilter in the pzGetGridColUniqueValues activity to allow filters to contain special characters.
SR-D88500 · Issue 562657
Eligibility prompt integer values sorted by incremental size
Resolved in Pega Version 8.4.2
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-D97193 · Issue 556552
DataView rules and library files removed
Resolved in Pega Version 8.4.2
After upgrade, the pzPresentationFUA library was failing while compiling with errors relating to references for com.pega.pegarules.priv.desktop.reporting.dataview not being resolved. This was due to an incomplete cleanup when data views were removed from use, and the library and rules have now been removed.
INC-120343 · Issue 573077
Explicit parent added for descendants in subreport to correct summary
Resolved in Pega Version 8.4.2
When using a Report Definition with a Summarize column and a subreport with join class, it was not considering implementation class work objects. As a result, the prepared values were only partially computed. This was traced to the SubReport in SetQuery not having reference to a parent for the descendants classes, and has been resolved by explicitly setting the parent value.