SR-D55289 · Issue 524108
FusionCharts upgraded to resolve drill down issues
Resolved in Pega Version 8.4
Drill down reports were not working when the results were displayed with huge data that came up with a scroll bar or if the report was scrolled down and a drill down was attempted when the scroll bar was in the bottom or middle of the scroll line. The hover icon was different i.e., the hand icon was replaced with arrow icon, or sometimes the hand icon displayed without showing the data. The tooltip was also not displaying as expected when hovering on the chart. It was possible to drill down when the scroll bar was in the top or the focus was moved outside the chart and brought back in again. This was traced to bugs in the FusionChart libraries, and has been resolved by upgrading to FusionCharts 3.14.0-sr.1.
SR-D55801 · Issue 524293
Corrected HTML error generated on export to PDF
Resolved in Pega Version 8.4
After exporting a report to PDF, the PDF could be viewed but repeated instances of the error "<th> missing ‘>’ for end of tag" were logged. This was traced to missing the closing '>' for th in the pzRRDataListHeaderRow HTML rule when "Enable column command menu" is unchecked in ReportViewer options, and has been corrected.
SR-D58552 · Issue 522088
Report Definition filter editing shows all values correctly
Resolved in Pega Version 8.4
After launching a report, certain values were not populated on the pop-up when editing the filters or the commas separating the values did not appear. This was traced to the activity pzGetSelectedValues containing an older implementation of column type checking, causing it to report some embedded property references as being of type "Included Page" instead of the type of the ultimate property. This has been resolved by updating step 1 to only use this logic if pyDataType is not set, which should already be set for all filters and columns, and the formatting has been corrected.
SR-D65937 · Issue 528980
Support added for calling Export to Excel directly from RD
Resolved in Pega Version 8.4
When using Export to Excel directly from a report definition, a date column specified using pxDatetime was shown as applied date format in the resulting Excel file. The column was formatted as expected if the export was called from an activity. This was traced to the recent refactoring of Export to Excel: it was not expected that it would be called directly, but rather that it would be invoked from a report viewer ruleform. In order to support this direct use, step calls have been added to the pzRDExportWrapper activity to call pzMergeAutoGen before the engine call. This step will merge the pyModes pages from pxDateTime control.
SR-D15395 · Issue 492053
Added DSS to handle BIX extracts under parse delimiter rules
Resolved in Pega Version 8.4
When parse delimiter rules were applied, the File Listener was not parsing the CSV manifest file generated from a BIX extract until the file was resaved. This was traced to a space after a comma in the extracted files, and has been resolved with the addition of a DSS which enables the use-specified delimiter to remove the space after the comma in the manifest files.
SR-D15872 · Issue 494476
Handling added for null result during BIX agent execution
Resolved in Pega Version 8.4
While executing one of the extract rules either manually from the Designer Studio or by using the back end BIX-Agent, an infinite loop caused agent rules to run indefinitely and create a server log size that impacted system performance. This was traced to reading a page from stream that was returned as null due to an exception, preventing the system from proceeding to the next result. To resolve this, the system has been updated to move to the next result if the current result throws an exception and returns as null.
SR-D17825 · Issue 494704
PreSaveAs updated to set the correct ruleset value when saved into a different ruleset
Resolved in Pega Version 8.4
When using a BIX Extract rule already configured with properties and filter criteria, attempting to update the filter criteria system resulted in an "invalid property error" and inability to save the updated rule. This was traced to the extract rule being created from another extract rule with 'save as', resulting in the new extract existing in a different ruleset. Because the pxBixReportPage.pyRuleset had the value of the original ruleset instead of rule set in which it had been saved, the system was attempting to find the filter properties in the original ruleset. To resolve this, the Presaveas activity in rule-admin-extract has been modified to check and set the correct value when both the rulesets are not equal.
SR-D21555 · Issue 501106
Resolved command line BIX/PRPCUtils creating unreachable nodes
Resolved in Pega Version 8.4
BIX and PRPCUtils scripts were creating nodes that showed as unreachable or that were never cleared. This was traced to a code change that resulted in nodes starting as stream nodes unless given a node type or DSS settings, and has been resolved by setting the asyncExecutor/enable setting value as false in the prconfig.xml. The BIX command line JVM argument should also be set to NodeType=BIX.
SR-D22075 · Issue 501345
Wild card character escape added for filtering data records
Resolved in Pega Version 8.4
It was not possible to export data type records which were filtered with either _ or % in the value. This was due to the characters being wild card characters in the SQL-like operator, and has been resolved by modifying the NativeSQLAPIResolver to add escapecharacter to the runtime value of the filter.
SR-D22468 · Issue 502037
Bix extract performance improved by only checking cipher type for encrypted properties
Resolved in Pega Version 8.4
Previously, if no cipher was configured in extract Rules the cipher type defaulted to null and wasn't cached. This caused performance issues when running against the database. In order to improve performance, the code has been modified to only check for cipher type if the property is encrypted. Performance issues were also seen when running a BIX extraction via the command line where the BIX extract was set to extract all properties, the BIX extract rule used Extract to XML, and DisableEpochDateTime and DisableEpochDate settings were not created and thus the default (false) value was used. This slowness was traced to the command line extract not caching the "miss" for the values of the Epoch settings and therefore repeatedly querying the pr_data_admin table for the date and datetime property for each record. Investigation showed that BIX was depending on DASS files that are not shipped out-of-the-box: since the DASSs were not present, the query to retrieve their value returned null and was not cached for future access. To resolve this, the system has been updated to pass default values for the two required DASSs if they are not present, ensuring a value will be cached and the DB query will not be fired unnecessarily.