INC-219086 · Issue 724268
Keypair handling updated
Resolved in Pega Version 8.8
Rest API calls were failing with invalid token error in production due to the keypairs used to encrypt the access token being different for each node. This happened when the keypair cache was maintained at node level instead of being retrieved from a database each time; when a keypair expired, a new keypair was created for each node instead of sharing one because the updates to keypair were not properly communicated among the nodes. To resolve this, a check has been added to see if a new keypair is already available in the database before creating a new keypair, handling has been added for any DuplicateKeyException that might occur while saving a keypair to the database, and a pxCreateDateTime has been added while storing the new keypair in the database. Please also note that the default key rotation period is now 180 days and can be adjusted through the setting AccessToken/KeyRotationInterval.
INC-211655 · Issue 712351
Added handling for Malaysian locale date/time
Resolved in Pega Version 8.8
When using the "ms_MY" locale for Malaysia, entering ‘14/02/2022 13:00’ in the displayed DateTime input field generated the error "14/02/2022 13:00 is not a valid date / time value." This was due to differences in the underlying Java version: in Java 8, the API PRDateFormat.getShortDateTimeFormat returns "dd/MM/yyyy h:mm" and the PRDateFormat.getAmPmStrings returns [AM, PM], but in Java 11, the API returns "d/MM/yyyy h:mm a" with PRDateFormat.getAmPmStrings returning [PG, PTG]. For the Malaysian locale ms_MY, the clock format is 12 hour and AM/PM Strings are PG, PTG. This caused environments running JDK11 to fail client side validation for date time when PTG (a 3-char AM/PM string) was selected. This has been resolved by adding handling for this usecase.
INC-207524 · Issue 714707
Handling added for modal flow to resolve unexpected submit window closure
Resolved in Pega Version 8.8
After creating a child Task and submitting the TaskCreation flow action, a validation error was seen. Clicking on the Submit button again caused the modal TaskCreation window to close. Investigation showed that the WorkLock activity was executed as desired on the first click on submit, but for the second submit the WorkLock activity called Obj-Refresh-And-Lock and the page was refreshed, the work object lock was released, and the error was no longer seen. To resolve this, an update has been made to the WorkLock activity to use a new when rule 'pyIsModalFlowTemporary' so that Obj-Refresh-And-Lock is not called twice. This change has also been added to pzRunFlow.
INC-234543 · Issue 743003
Parameter value with carriage return evaluated correctly
Resolved in Pega Version 8.8
If a text area control had multiple lines entered in it and the same text area was passed as a parameter to a Data Transform executed at the launch of a read-only harness, the value in the text area was - " #~pyworkpage.propertyname". If the text area had just a single line without any enters/multiple lines, then it worked as expected. This was traced to the handling in pzpega_ui_events and has been resolved by escaping the newline and carriage return characters. An additional issue found when using multiselect in the form was traced to the correctActionArgs function which was generating the replacedtoken "//string//" for one of the property subjectareadetails, and this has been corrected.
SR-C69441 · Issue 415966
Copy/Merge Wizard ProcessRequest will create new rule instead of modifying the old
Resolved in Pega Version 8.2
When using the Copy/Merge wizard to move the rules from one ruleset to another with the "Delete Source RuleSet(s) upon completion of merge" option set to YES, the SECTION rules were still being referred even though the target ruleset was not part of the application stack. In the Tracer, it could be seen that the rule appears in the source ruleset version even though the ruleset did not exist, and attempting to open the rule from tracer or from Live UI caused it to open in the Target ruleset version (which was not part of application). This was traced to the system not updating the cache, leading to RULE-OBJ-ACTIVITY PEGAACCEL-MANAGEMENT-REFACTOR-RULESET PROCESSREQUEST applying an incorrect strategy when updating the rule and rulesets. Because the original rule was never invalidated, its shortcut and entry remained and any references to it weren't updated. To correct this issue in a comprehensive way, the ProcessRequest has been modified to create a new rule instead of modifying the old rule, and pxCreateDateTime will be added to the rulepage before saving.
INC-217904 · Issue 730432
New prconfigs added to handle lob closed error
Resolved in Pega Version 8.8
BIX extraction was encountering the SQL error "Invalid operation: Lob is closed" while reading the BLOB, but the rest of the records were able to be extracted. This was traced to previous work done to resolve an issue where Oracle temporary space used to write the LOB was not freed up after writing records to Log-Service-File when using OJDBC8 or OJDBC10 versions. This change caused an issue for DB2 where the freed BLOB was still trying to be extracted. To address this, new prconfig settings have been introduced to control freeing BLOB memory. If the error is seen regarding the lob being closed, add and disable these settings (set value as false) in the pronfig.xml file. DATABASE_MANAGEMENT_FREELOB: settingName: database/management/freeLOB description: If this flag is set to false, it controls the free memory calls defaultValue: true DATABASE_MANAGEMENT_FREEPAGEDBMAPPERLOB: settingName: database/management/freePageDBMapperLOB description: If this flag is set to false, it controls the free memory calls. defaultValue: true Following this change, restart the server.
INC-218802 · Issue 736911
New prconfigs added to handle lob closed error
Resolved in Pega Version 8.8
BIX extraction was encountering the SQL error "Invalid operation: Lob is closed" while reading the BLOB, but the rest of the records were able to be extracted. This was traced to previous work done to resolve an issue where Oracle temporary space used to write the LOB was not freed up after writing records to Log-Service-File when using OJDBC8 or OJDBC10 versions. This change caused an issue for DB2 where the freed BLOB was still trying to be extracted. To address this, new prconfig settings have been introduced to control freeing BLOB memory. If the error is seen regarding the lob being closed, add and disable these settings (set value as false) in the pronfig.xml file. DATABASE_MANAGEMENT_FREELOB: settingName: database/management/freeLOB description: If this flag is set to false, it controls the free memory calls defaultValue: true DATABASE_MANAGEMENT_FREEPAGEDBMAPPERLOB: settingName: database/management/freePageDBMapperLOB description: If this flag is set to false, it controls the free memory calls. defaultValue: true Following this change, restart the server.
INC-220251 · Issue 732073
New prconfigs added to handle lob closed error
Resolved in Pega Version 8.8
BIX extraction was encountering the SQL error "Invalid operation: Lob is closed" while reading the BLOB, but the rest of the records were able to be extracted. This was traced to previous work done to resolve an issue where Oracle temporary space used to write the LOB was not freed up after writing records to Log-Service-File when using OJDBC8 or OJDBC10 versions. This change caused an issue for DB2 where the freed BLOB was still trying to be extracted. To address this, new prconfig settings have been introduced to control freeing BLOB memory. If the error is seen regarding the lob being closed, add and disable these settings (set value as false) in the pronfig.xml file. DATABASE_MANAGEMENT_FREELOB: settingName: database/management/freeLOB description: If this flag is set to false, it controls the free memory calls defaultValue: true DATABASE_MANAGEMENT_FREEPAGEDBMAPPERLOB: settingName: database/management/freePageDBMapperLOB description: If this flag is set to false, it controls the free memory calls. defaultValue: true Following this change, restart the server.
SR-C62241 · Issue 405941
Error handling corrected for Actions/Refresh menu actions
Resolved in Pega Version 8.2
When using the ACTIONS / REFRESH menu action on a case that had a required property, the busy indicator appeared and remained on screen, blocking interaction with the portal until the browser was refreshed. The error "pzpega_ui_harness_deferred_ts_1342430166!!.js:1969 Uncaught TypeError: Cannot read property 'stopPropagation' of undefined at Object.stopPropagation" appeared. This was traced to a fault in the error handling and has been corrected by modifying "pzpega_control_actions_refresh.js" so the event will be passed as parameter in the "pega.u.d.submitWhenFail()" call and the "SubmitInProgress" value will be set in context in pzpega_ui_doc_submit.js.
INC-218543 · Issue 729993
Control added for Deployment Manager guardrail evaluations
Resolved in Pega Version 8.8
When using the Deployment Manager merge pipeline to merge branches from a development system, an exception was raised raised by the pzQueueProcessRuleForGuardrails activity of the Standard Queue Processor after every merge was completed even if it compiled successfully. As a result, after every branch merge a new broken queue item remained in the queue of this processor. Investigation showed the Deployment Manager creates and deletes Rule-Admin-Product instances faster than they can be queued for processing, resulting in this error. This has been resolved by creating pyIsApplicationGuardrailsEvaluationEnabled in Rule-Admin-Product that always resolves to false so that Product rules created by Deployment Manager do not create errors in pzQueueProcessRuleForGuardrails.