Skip to main content

Resolved Issues

View the resolved issues for a specific Platform release.

Go to download resolved issues by patch release.

Browse release notes for a selected Pega Version.

NOTE: Enter just the Case ID number (SR or INC) in order to find the associated Support Request.

Please note: beginning with the Pega Platform 8.7.4 Patch, the Resolved Issues have moved to the Support Center.

SR-D6555 · Issue 457241

Access When check added for pyStartCase privilege

Resolved in Pega Version 8.1.6

If a privilege was defined in the pyStartCase flow rule and the access role to object assigned a privilege based on 'Access When' (not production level), the user was not able to start a case. This was traced to the havePrivileges RUF passing an incorrect primary page to evaluate the privileges in combination with the 'access when'. To resolve this, the engine API will call tools.getAuthorizationHandle().havePrivilege for each privilege until it finds a match.

INC-160178 · Issue 632895

Local time used for report filters

Resolved in Pega Version 8.4.5

The date format in the filter condition of the report was being displayed in GMT format rather than the Local time Format. This has been corrected.

SR-D27687 · Issue 500053

Mashup Export to Excel works on first use

Resolved in Pega Version 8.1.6

If a report was opened from Mashup and exported to Excel, only one record was given regardless of the actual size of the report. If the mashup main page was refreshed, the open and export process worked correctly. This has been corrected by adding a call to pzSetQueryDefaults in pzRDExportWrapper when the requestor is initialized for Mashup.

INC-157696 · Issue 623883

Able to add message to Pulse when it includes "@."

Resolved in Pega Version 8.4.5

Messages that contained the "@." character, like "@.com", "@.es" or "personas@..." were not being added in Pega Pulse. This has been resolved by setting the workid prefix in pyDefault of PegaSocial-Group and adding a check to see if the mentioned item starts with a workid prefix before doing an obj-browse.

SR-D17919 · Issue 491581

Corrected thread switching when moving between interactions tabs

Resolved in Pega Version 8.1.6

When using Create New for a Phone Call-Consumer in one tab and Create New for an Outbound Phone Call on another tab, the thread was not changing when switching between the tabs of the interactions. Closing the Outbound call interaction resulted in null pages on the clipboard. This has been resolved by updating the pzpega_ui_doc_tabsupport file so it switches to root document context if called from onActivate function using a flag.

INC-171449 · Issue 649931

Added null check for expression ID in Disable-When-Condition

Resolved in Pega Version 8.4.5

A Radio Button was not disabled despite a 'when' rule if a Data Page was used as the List source in the Radio buttons control and the property was passed as a parameter of the data page. Investigation showed that the expression ID for the Disable-When-Condition was present, but there were no expressions to evaluate. This has been resolved by adding a null check to verify if expressionResults is an empty object.

INC-156818 · Issue 628465

Materialization uses time limit boundary for query

Resolved in Pega Version 8.4.5

After turning on Materialization for pyIHSummary and OfferOutcomesForPast45Days datasets, an SQL query was taking an excessive amount of time and causing multiple alerts in the logs. Investigation traced the issue to database partitioning, specifically that running a query where the pyOutcomeTime range spanned multiple partitions was causing the indexes for all partitions in the range to be opened. To resolve this, the query has been updated with a DSS to support a partition size of min(pxOutcomeTime) to limit the time range to querying day by day, or hour by hour, or any other chronology unit specified. If there are no records for the current limit, then it will look at the next partition. This should prevent the query from needing to open more than 1 or 2 partitions.

SR-D21808 · Issue 490282

Filter values retained when editing a report with custom filters

Resolved in Pega Version 8.1.6

After running a report, if some filter values were selected and then the Edit Report button was clicked and simulated data and actual data fields were toggled, the filter values were lost when exiting the report editor. In the Edit Report Page, trying to drag a new filter condition was not working and the Change logic buttons were not visible. These functions worked as expected when a custom Filter section was not used. This was traced to the custom filter page being cleared in the pzCreateCustomFilterPage activity where the step for creating new page should be skipped if it already exists. To resolve this, a parameter will be set to show if the report was rerun in "reRunReport", and a check has been added in pzCreateCustomFilterPage to see if the report was rerun before running the other 'when' conditions.

INC-158813 · Issue 629484

Updated report handling for simulations using database output

Resolved in Pega Version 8.4.5

When running a simulation with a database table as the output destination, the pxObjClass property was not populating with a value in the results. This caused sub-reports to not be populated with data. Investigation showed that issue happened when the simulation output destination database table was inferred as an external table due to not having an exposed column for pzinskey. To resolve this, the pxObjClass and pxCreateDateTime properties, which were added to simulation output destination tables for compatibility with Report browser, will not be added to those tables when they are created. Instead, to address compatibility issues of simulation output destination classes with Report browse in the Customer Decision Hub, the pyDefaultSummaryReport has been brought up into the Data-Decision-StrategyExecution-ResultOutput class from the @baseclass.

SR-D20817 · Issue 499921

Async cache checking updated for interaction reload use

Resolved in Pega Version 8.1.6

A thread level data page using connect REST to get data from an external system with the "Reload once per interaction" checkbox ticked was being loaded asynchronously from the activity when by default the data page it was supplying needed to be loaded synchronously. Due to this, changes to the data in the external database were not reflected in the data page. This was caused when an async cache was referred and the freshness check for the data page instance did not consider the 'reload once per interaction' flag because it would cause the data page to load twice. The cache checking has been updated to resolve this.

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us