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 update your bookmarks. This site will be discontinued in Dec 2024.

Pega Platform Resolved Issues for 8.1 and newer are now available on the Support Center.

SR-121632 · Issue 183997

RefreshOnConflicts changed for better locking

Resolved in Pega Version 7.1.8

During work flow processing, using the Out-Of-The-Box "Refresh" action and then submitting the current assignment removed the ability to submit the following assignment and an error was generated: "You have lost the ability to make this change because a change elsewhere has taken precedence over the change you made here. Please click on the assignment again to continue." If there are back-to-back assignments and the 'Refresh on Other' action is clicked first, when the second assignment is submitted this lost locking error is displayed. To resolve this, the RefreshOnConflicts activity has been changed to invoke ProcessAssignment on newAssignPage instead of WorkPage so that the locking mechanism will function as expected.

SR-123478 · Issue 186770

Defined order of execution for FinishAssignment and pyDeleteDocumentPg

Resolved in Pega Version 7.1.8

In an application in which a page-level message was to be output if a certain field was left blank, sometimes the page-level message did not display when the condition was met. This problem was due to the random order in which pyDeleteDocumentPg and FinishAssignment were issued by the Browser. Both are issued simultaneously to within the same 1000th of a second (according to Fiddler), but sometimes one is issued first, sometimes the other is issued first. Whether or not the function succeeded depended on whether or not pyDeleteDocumentPg was processed first by the server. In order to ensure the proper behavior, the submit and harnessOnBeforeUnload methods defined in pega.u.d object have been modified to send the finishAssignment request after processing the pzDeleteDocumentPg request.

SR-A86387 · Issue 260734

Filename check updated for saving java sources to DB

Resolved in Pega Version 7.2.2

A "Problem saving Java sources to database" error was observed in the log intermittently in a system with java security enabled at web server level when there was an attempt to save assembled classes to the database with an incorrect package name (the full file path instead of com.pegarules.generated...). Before the save is done, there is a check on the package name to see whether it starts with "com.pegarules.generated" to ensure that only generated classes are saved to the database. With Java Security enabled, the system specified the entire file path as the package name and the check failed. To resolve this, the existing function has been modified to use the package name instead of the full file path.

SR-C7762 · Issue 350154

Commas removed from filter values to resolve validation errors

Resolved in Pega Version 8.1

When using a Grid layout configured in a section rule, clicking the Filter option and entering a comma separated value in the "To" field in a decimal-type column resulted in an "Invalid numeric range" option message. No error was seen if comma separated values were entered in both the "To" and "From" fields. Because the checkRangeFilter() function in ui_grid.js uses parseFloat() API to extract the decimal content entered in the search boxes, decimals after commas are ignored and validation failed due to the fields not matching. This issue has been fixed by implicitly removing any commas entered by the user.

INC-136208 · Issue 585228

Case history filter added for manual instantiation of Child Case

Resolved in Pega Version 8.3.5

After upgrade from v7.4 to v8.3, creating any child case from a parent case unexpectedly added the audit history "Child case xxxxx has been manually instantiated" to the parent case. In order to make this customizable, an "isHistoryAvailable" function has been added in the 'when' condition of "AddCoveredWork" Activity's "History-Add" Step. This will use the FilterHistory decision tree, which now has a setting for "ChildCaseInsAudit" to control whether or not the manual Instantiation of a Child Case will appear in the case history. The default is "true"; setting it to "false" will suppress the message.

SR-C25839 · Issue 368838

Fixed Merge Wizard silent failure and added checks for ":" in RuleSetName value

Resolved in Pega Version 8.1

If an error occurred when using the Merge Wizard, the merge case was resolved-rejected without any reason or error message. This was caused by a hidden “Required Rulesets and Versions” field on the RuleSet ruleform which set the ruleset to application based validation. In addition, some ruleset validation logic was triggering even in ABV mode. To correct this, the precondition in pzOpenAllSourceRuleSets 2.2 has bene changed from "pyIsSourceABV"=="true" to .pyIsSourceABV=="true", and the pzRuleSetNameIsABranch function now has support for handling the null pointer exception when the RuleSetName value is ":". A message will also be logged if the RuleSetName starts with ":".

SR-D1386 · Issue 446261

Warning message visibility conditions updated for Records Editor

Resolved in Pega Version 8.3

The Report Definition Result screen was showing the message "Warning : We were unable to create columns to match the new properties added. This will cause performance problems when using this data type. Please click here to fix this." Along with the RD results screen, this particular warning message was also shown in the Records tab of the respective Datatype. Initially, the Records Editor was developed for Designer Studio and Express usage. When the delegation functionality was later given to portals, the 'when' condition for the warning message was not updated to restrict displaying it to portal users. This has been fixed by updating the pzManageRecords section to properly manage the visibility condition of the warning message.

SR-D55841 · Issue 522696

isAvailable calendar instance will include time zones

Resolved in Pega Version 8.4

When using a custom configuration to route assignments, if today was configured as unavailablefrom date, assignments were still routed to the current operator even though they were not available. Analysis showed that the same Calendar was not used to compare date objStartDate, opUnavailableFrom and opUnavailableTo in the function, isAvailable. The isAvailable FUA calculates objStartDate by getting the calendar instance and setting the time by calculating it from the next business day. However, the calendar instance was created from Calendar.getInstance(), which does not use a time zone, and this resulted in a mis-match of time. To resolve this, instead of creating a calendar instance objStartDate will be formatted to YYYYMMDD format and then converted to the requestor time zone timings using Data Time Utils parseDateTimeString.

INC-136208 · Issue 585227

Case history filter added for manual instantiation of Child Case

Resolved in Pega Version 8.6

After upgrade from v7.4 to v8.3, creating any child case from a parent case unexpectedly added the audit history "Child case xxxxx has been manually instantiated" to the parent case. In order to make this customizable, an "isHistoryAvailable" function has been added in the 'when' condition of "AddCoveredWork" Activity's "History-Add" Step. This will use the FilterHistory decision tree, which now has a setting for "ChildCaseInsAudit" to control whether or not the manual Instantiation of a Child Case will appear in the case history. The default is "true"; setting it to "false" will suppress the message.

INC-164311 · Issue 635785

Correct datetime target property used

Resolved in Pega Version 8.6

When using a declare expression for a datetime property to get its value from another datetime property, attempting to change the source datetime later resulted in the error "28-mar-2021 is not a valid date/time value". This occurred when the source datetime property had display readonly formatting, and was traced to the formatted value being sent in the callGetTargets API instead of the selected date value, which caused the function to be returned as empty because there was no target property in the same page before submission. To correct this, a check has been added which will get the value from data-value instead of element.value and will skip callGettragets if the target is empty.

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