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-D76567 · Issue 545448

ABAC DSS setting reflected in all nodes

Resolved in Pega Version 8.2.6

When the ABAC (Attribute-based access control) DSS was disabled, the change was not reflected in all the nodes automatically. This was traced to a difference in parameter name: SecurityCacheProvider.pulseChange(), while consuming pulse message on another node, expects to get ".pyPurpose" from the StringMap. Because the system was setting "pyPurpose", aKeys.get(".pyPurpose") returned nothing, and the policy cache iwa not cleared on other nodes. This has been resolved by ensuring naming consistency with "pyPurpose".

SR-D78045 · Issue 539891

Cleanup added for staging directory

Resolved in Pega Version 8.2.6

Temporary files from imports and exports (from DevOps) were filling up the staging area disk space because there was no automatic process for cleaning up these local files. This has been resolved by adding an enhancement that will clear the directory on Engine Startup and any time ParUtils.setStagingDirectory gets called to initialize the staging directory.

SR-D78987 · Issue 544061

Support for custom jvm.args added

Resolved in Pega Version 8.2.6

In order to support Oracle PKI and other ticket based authentication, support has been added for custom jvm.args properties to setupDatabase and prpcUtils properties files.

SR-D79178 · Issue 543312

SameSite cookie setting added for Mashup support in Google Chrome v80+

Resolved in Pega Version 8.2.6

The Google Chrome browser version 80 and above now treats SameSite with a blank value as "Lax" by default, causing mashup scenarios to break. In order to compensate for this change, support has been added for setting SameSite=None in Cookie Settings in the CSRF LP (DevStudio-> System-> Setting-> CrossSiteRequestForgery) which will enforce HTTPS for the Pega server and mashup. Note: The SameSite cookie may be set to None/Lax/Strict, based on the requirement. For mashups to work, SameSite should be set as None. To follow proper security standards, it should be set as Strict.

SR-D83053 · Issue 544268

SameSite cookie setting added for Mashup support in Google Chrome v80+

Resolved in Pega Version 8.2.6

The Google Chrome browser version 80 and above now treats SameSite with a blank value as "Lax" by default, causing mashup scenarios to break. In order to compensate for this change, support has been added for setting SameSite=None in Cookie Settings in the CSRF LP (DevStudio-> System-> Setting-> CrossSiteRequestForgery) which will enforce HTTPS for the Pega server and mashup. Note: The SameSite cookie may be set to None/Lax/Strict, based on the requirement. For mashups to work, SameSite should be set as None. To follow proper security standards, it should be set as Strict.

SR-D83192 · Issue 545057

JobScheduler DST handling updated

Resolved in Pega Version 8.2.6

When the locale being used changed out of Daylight Savings Time, scheduled jobs did run at the same local time as before but instead ran an hour earlier than expected. Investigation showed that jobscheduler calculated the next runtime based on the time difference from the cluster reference time and current time in milliseconds, and this offset in milliseconds was added to next run time. Since the cluster was started in DST, the job was running on same time due to the time difference. To resolve this, the system will use a calculation offset and set hours/minutes to nextRunTime object so that calendar lib handles daylight savings.

SR-128961 · Issue 208349

Added check for naming conflicts when upgrading Oracle

Resolved in Pega Version 7.2

When attempting to upgrade a single schema on Oracle database, running the generateddl script failed with a NullPointerException. This was caused by database tables which had a column name called 'SYS_ID' as part of the primary key. Since Oracle uses system-generated names beginning with "SYS_" for implicitly generated schema objects and subobjects, Oracle discourages the use of this prefix in the names explicitly provided to the schema objects and subobjects in order to avoid possible conflicts in name resolution. To resolve this, a tester has been added to the system to check for this naming use and issue a warning.

SR-132637 · Issue 203591

Added path checking to FirstLogCreationTime.log

Resolved in Pega Version 7.1.9

FirstLogCreationTime.log was being written to a temp folder using hard-coded logic to use a relative path within the install directory. This caused errors if the installer was trying to write the logs in an absolute path. FirstLogCreationTime.log should be written to the same directory as the rest of the logs, and this issue has been fixed by adding a condition in LogDeleteUtil.getLogCreationTimeFile() method to check for absolute paths.

SR-133747 · Issue 203813

Corrected hashtag handling for Oracle SQL generation

Resolved in Pega Version 7.1.9

Given a column name with a hashtag in an Oracle environment, the system was compiling SQL statements which caused ORA-00904 errors due to replacing the # in one variable name with an _ but leaving it as a # in another. This has been corrected.

SR-133057 · Issue 205124

System updated to better handle multi-node rule resolution

Resolved in Pega Version 7.1.9

In an upgraded multi-node environment, the error 'com.pega.pegarules.pub.database.MultipleRuleVersionException: Rule resolution identified 2 versions of the rule' was sporadically appearing. Once the issue occurred, it would persist and the only way to resolve it was to bounce the server. This was an issue with an instance of one rule being found in one node and not found in other node, and was related to the trigger logic. This should not occur with the current Pega7 version, as trigger logic has been moved into the engine and there is no longer a database trigger to fix. In order to ensure continued smooth trigger resolution, tests have been added that will check for this condition in the updates cache table to ensure that this scenario does not occur again

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