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-D64220 · Issue 535133

Reinitializing Full Text Search will shut down Elastic Search regardless of search initialization status

Resolved in Pega Version 8.4

Pega search was only sporadically working after converting from standard sandbox-marketing to largesandbox-marketing. This was traced to the Full-Text Search initialization having failed on the app-tier node during re-initialization. As part of re-initialization, the existing node is shut down and the Elastic Search node is started. The shutdown process relied on a boolean flag which indicated if the current status of full-text search initialization was successful. In this case, ES was trying to validate all the cluster level settings, for every save of one of the cluster level settings, but could not due to topology changes in the Util Tier node. The boolean flag indicated initialization had failed so the shutdown process was not invoked, yet the system was attempting to start the second instance of an ES node on the same machine. To resolve this, the shutdown FTS code has been modified to shutdown ES regardless of the search initialization status.

SR-D65944 · Issue 533395

Parent case lock properly released when child case is resolved

Resolved in Pega Version 8.4

After creating Parent-Child casetypes with default locking where the child case had the “Allow access to parent” check box checked, the temporary lock acquired on the parent during resolution of the child case was not released afterwards. If “Allow access to parent” was not checked, then the locks were released on both the parent and the child. This was traced to a combination of parameters used by the openIfStale() API where aUnlockOnCommit could be set to false despite the provided locking strategy expecting it to be true, as well as honoring UnlockOnCommit when maintainLockingStrategy is false. To resolve this, the system has been updated to always check whether the lock is available in the map already and if it is, then set unlockonCommit to true. Otherwise, under all cases, honor the passed-in unlockOnCommit value.

SR-D16427 · Issue 495818

Multi-nodes rebuild LibraryMetadata to ensure all Rule-Utility-Functions are present on change

Resolved in Pega Version 8.4

When performing a complete Application import into a clean installation, references to certain Rule-Utility-Functions went unresolved during the initial assembly. Investigation showed that after introducing a new Rule-Utility-Library or Rule-Utility-Function on one node in a cluster and then generating that, the other nodes in the cluster did not have the correct LibraryMetaDataCache for that Rule-Utility-Library.Therefore assemblies on those other nodes could be bad and throw a runtime UnresolvedAssemblyError. This has been resolved by modifying the way the Library subsystem processes the node changes events for Library Generation to ensure that each node completely rebuilds the LibraryMetadata for that Rule-Utility-Library so it contains all the Rule-Utility-Functions.

SR-D18120 · Issue 496424

JMS push notification made more robust

Resolved in Pega Version 8.4

After creating a JMS Service to call pySendPushNotification from an activity, running it using User Context worked as expected but selecting initialize Service Context resulted in the Push notification silently failing in the context of JMS service. The JMS is used as a communication medium between legacy and Pega solutions. When the message arrives, Pega creates a new case and sends a push notification to the user, who has only 2 minutes to accept the case. Because of the urgency of timeliness in this situation, the push is sent directly from the context of the service rather than expend 30 seconds for agent processing. However, because the application was not always available to the pySendPushNotification activity (and further to API call), the push failed. In order to avoid this condition, the system has been modified to use the more widely available pxThread instead of Application when possible.

SR-D24187 · Issue 506128

Catch block added to handle invalid FindAndUpdateElement clipboard data

Resolved in Pega Version 8.4

An exception was generated relating to "Unable to passivate page on thread '<savedwork>' . The following items were not serializable: [Property not serializable: "Declare_pyDisplay.pyDisplay(InteractionPortal).pyUIElements(3).pyParameters.activityParamPage" Class: "com.pega.pegarules.pub.runtime.ParameterPage." This was traced to invalid data in the clipboard, and has been resolved with the addition of a catch block in pzFindAndUpdateElement Rule-Utility-Function which will put an empty string in the clipboard whenever there is an invalid value in the 'Declare_pyDisplay.pyDisplay().pyUIElements().pyParameters' clipboard page.

SR-D24261 · Issue 492559

Updated retry for context registraton

Resolved in Pega Version 8.4

The system was intermittently hanging after importing zipped files. Investigation showed that Batch threads were becoming stuck in AuthorizationContextManagerImpl.setSpecializations() due to a 'while' loop in setSpecializations that was seeking to register the new context. To resolve this, logic has been added which will try to register up to 10 times. If for any reason it can't register, the system will just return the unregister LAC. The check before deregister has also been enhanced and now will only deregister if the new context and the current context are different. It will not call register if the current context and the new context are the same.

SR-D25163 · Issue 504612

Improved query efficiency for bulk processing

Resolved in Pega Version 8.4

Spikes were observed in Library Cache usage. These were traced to queries that originated from Agent 'AgentBulkProcessing' and the activity 'PzAgentBulProcessing' that used "like" and "as", which were not performance efficient in a large-scale installation. The queries in the CheckBulkProcessQueue activity have now been updated to improve performance.

SR-D28985 · Issue 498017

Improvements made to Excel data import handling for decision tables

Resolved in Pega Version 8.4

On importing an Excel file into a decision table, the values modified in Excel were getting updated even though the rule was checked in after the import. Investigation showed that the API which handled converting the imported Excel file for use on the clipboard was defaulting to save actions if the rule was not checked out or in private edit before the import. In order to prevent future issues, the following changes have been made in this area: The "Import" button will be enabled only after clicking on checkout button, and discarding the checkout will also discard any imported values. When checkout for the rule set is disabled, only the save option will be displayed on the decision table. When the import button is visible and enabled, imported values will not be preserved if Actions -> Refresh is used before saving. When rulesets are disabled, the decision table can only be private edited and at that time the save and import buttons will be visible. When private edit is visible, the import button will be in a disabled state.

SR-D28996 · Issue 520717

External Mappings set for History Rule tab of class display

Resolved in Pega Version 8.4

After creating a class rule with external mapping columns and saving the rule, attempting to restore the previous saved snapshot from the full history of the class rule resulted in the external mapping tab being displayed with empty rows. This was traced to "External mappings" not being set when displaying the History Rule, and has been resolved by adding a call to RULE-OBJ-CLASS!OPENDEFAULTS to set the mapping properties.

SR-D33214 · Issue 514024

Added safeURL encoding for Japanese characters in attached filenames

Resolved in Pega Version 8.4

It was not possible to preview a Japanese-titled PDF file attached on a work object. Investigation showed that in case of Japanese characters, file names were not being correctly encoded during the fetch request when JBoss was used. The retrieval worked correctly under Tomcat. In order to ensure consistent encoding, the safeURL API will be used for constructing the URL and for the activities DisplayAttachFile and pzDownloadFromRepository which add the ContentDisposition header.

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