SR-D57855 · Issue 521126
Context retained during nested automation
Resolved in Pega Version 8.4
Issues were seen with context being passed correctly with automation. When a Data Page that was used to abstract the call to a REST API used a Data Transform which in turn used a Data Page which also used a call to a REST API to retrieve an OAuth Token, an error appeared. The same worked when a URL was provided on the Connect REST. When a service case was launched but a Flow Action wasn't submitted, then another service case was added and submitted, the post-processing robotic automation activity used the run robotic automation activity from the previous service case instead of the current service case targeted for completion. This has been resolved by updating the webwb • pzpega_ui_doc_submit.js file to pass the correct MDIContext based on the event target of FA submission while invoking RDA automation.
SR-D58194 · Issue 524702
Declarative cache resolved based on tenantId
Resolved in Pega Version 8.4
After upgrade, creating a case type (Assistance request) with a customized Create view was generating an exception error during the RecalcuateAndSave activity (in step 6). This was traced to a NullPointerException when building a declare expression cache entry for a property and was due to the class on which the expression was defined not being present in the current tenant. To resolve this, Declarative cache will be resolved based on tenantId.
SR-D61253 · Issue 527656
Exception stack trace will be included as comments in generated assembly code
Resolved in Pega Version 8.4
When there is an exception during assembly time, that original exception message is assembled in the generated code. To improve the process of finding the the root cause by examining the original exception stack, the system has been updated to insert the original exception stack trace into the generated code as comments.
SR-D62355 · Issue 529679
ClassName retrieved from rule definition when root record comes from primary page
Resolved in Pega Version 8.4
A When rule with single condition .DateProp >= .DateTimeProp was returning true when DateProp was set to a certain date & DateTimeProp was set to a date after DateProp. This was expected to return false. Investigation showed this was a missed use-case for property expressions where the root record came from the Primary Page, and was traced to an issue with the values being converted to String and the class not being set properly when the IL Assembler was used to resolve the Primary.IntegerProp's type. This has been resolved by returning the pyClassName retrieved from the rule definition page.
SR-D64406 · Issue 525252
Tracer issues resolved for Google Chrome broswer
Resolved in Pega Version 8.4
Tracer was running in the background even after the tracer window was closed. Attempting to run a Tracer in this condition resulted in an error indicating the Tracer was being run by another operator and should be restarted, and in the Dev environment, attempting to start a Tracer once it was closed resulted in the message "Cannot launch multiple Tracer sessions for a requestor." Investigation found that the Tracer session was not being closed when the tracer window was closed because the browser specific method intended to do so was not being called. This was found to be an issue caused by the Google Chrome browser changing the signature of the method, and has been resolved by updating the method name in the TraceMain HTML rule.
SR-D64570 · Issue 528960
Thread deadlocks during RAP imports resolved by reusing query results
Resolved in Pega Version 8.4
When using a time-intensive large query to build a cache to hold complex property references, multiple threads on a single tenant executed this query in a sequential manner and thread locking problems were seen. To resolve this, an update has been made so that for the same tenant, only one thread will run the query. All other threads waiting to acquire the lock will not execute the same db query but will instead make use of the result fetched by the first thread.
SR-D69836 · Issue 529730
Context retained during nested automation
Resolved in Pega Version 8.4
Issues were seen with context being passed correctly with automation. When a Data Page that was used to abstract the call to a REST API used a Data Transform which in turn used a Data Page which also used a call to a REST API to retrieve an OAuth Token, an error appeared. The same worked when a URL was provided on the Connect REST. When a service case was launched but a Flow Action wasn't submitted, then another service case was added and submitted, the post-processing robotic automation activity used the run robotic automation activity from the previous service case instead of the current service case targeted for completion. This has been resolved by updating the webwb • pzpega_ui_doc_submit.js file to pass the correct MDIContext based on the event target of FA submission while invoking RDA automation.
SR-D8754 · Issue 497379
Tracer issues resolved for Google Chrome broswer
Resolved in Pega Version 8.4
Tracer was running in the background even after the tracer window was closed. Attempting to run a Tracer in this condition resulted in an error indicating the Tracer was being run by another operator and should be restarted, and in the Dev environment, attempting to start a Tracer once it was closed resulted in the message "Cannot launch multiple Tracer sessions for a requestor." Investigation found that the Tracer session was not being closed when the tracer window was closed because the browser specific method intended to do so was not being called. This was found to be an issue caused by the Google Chrome browser changing the signature of the method, and has been resolved by updating the method name in the TraceMain HTML rule.
SR-D16678 · Issue 511271
FTPS server connections repaired
Resolved in Pega Version 8.4
When attempting to connect and transfer files to an FTPS server, errors were seen and the files did not transfer. This has been corrected by updating the system to send a PSBZ command before sending PROT in the FTPS implementation.
SR-D19111 · Issue 496593
Improved compatibility for mapping pyMessageId with out-of-the-box email index rule
Resolved in Pega Version 8.4
After upgrade, the process used for retrieving a reply for an email sent automatically by the system and comparing it with the incoming email to determine if it was a reply or not was failing to trigger an index or find instances of the class Data-Corr-Email that was supposed to save the property pyMessageId. This was related to recent refactoring of the handling for email headers in the Send activity, which moved them from a created AttachmentPage to the Primary page. The code in SendEmailNotification was still checking for the headers to be in the old location when going and adding the messageID, and was not taking it from the parameters. To resolve this, the pyMessageID will be set on the Primary page and messageID will be set on the parameter page based on the messageID in emailHeaders on the PrimaryPage.