SR-D22075 · Issue 501344
Wild card character escape added for filtering data records
Resolved in Pega Version 8.2.3
It was not possible to export data type records which were filtered with either _ or % in the value. This was due to the characters being wild card characters in the SQL-like operator, and has been resolved by modifying the NativeSQLAPIResolver to add escapecharacter to the runtime value of the filter.
SR-D27528 · Issue 501370
Return from drilldown in frameless portal corrected
Resolved in Pega Version 8.2.3
Drill up after drilling down on a dashboard chart in a frameless portal (such as Case Worker or Case Default) was throwing an exception. This was caused by the top-level page generated during drilldown not having pyRetainPage set to true, causing it to be removed from the clipboard by doUIAction. This has been resolved by updating runReport to set pyRetainPage if it needs to create the top-level page.
SR-D18726 · Issue 501389
Application quality page retains info on reopen
Resolved in Pega Version 8.2.3
When the application quality page was accessed for the first time the page displayed all the data properly, but if it was closed and then opened again all the counts were blank. This was traced to an issue with converting the date from the client to the database, and was seen when the Oracle database had date filed as key and type date. The issue did not occur if the type was varchar2. To resolve this, the system will use obj-open-by-handle instead of obj-open while fetching the details of AQD.
SR-D29926 · Issue 501407
FormatType reset added to ensure accurate DateTimes
Resolved in Pega Version 8.2.3
Read-only Date Time fields in the Case Information screen were displaying just the Date in Review Harness mode but displaying Date and Time properly in perform mode of the case. This was traced to a scenario where if any section which had only a date property was rendered in non-template, then 'pyFormatType' was being set as 'date' in tools and not reset afterwards. That meant any datetime type property rendered after this date property was rendered without a timestamp. This has been corrected.
SR-D31683 · Issue 501498
Corrected report harness popup display and drilldown return in frameless portal
Resolved in Pega Version 8.2.3
After configuring the pyCMReportBrowser7 Harness in the Application Menu and executing the report, clicking on the Drill down report displayed the report on the Main work area and Application Header,Footer, Menu. This happened only when a report with custom filters was loaded on a no-frame portal like caseworker, and was traced to portal chrome(header/sidepanel/footer) being added to every harness in no-frame portals to handle top navigation for every desktop action. In this case, when a report filter was opened in popup, the target parameter that held the "popup" value was lost by the time the submit button was clicked on filter window. To resolve this, a new property pyReportTarget has been added will use the target parameter value in the pzValidateCustomFilterSection activity. In addition, Drill up after drilling down on a dashboard chart in a frameless portal (such as Case Worker or Case Default) was throwing an exception. This was caused by the top-level page generated during drilldown not having pyRetainPage set to true, causing it to be removed from the clipboard by doUIAction. This has been resolved by updating runReport to set pyRetainPage if it needs to create the top-level page.
SR-D33133 · Issue 501633
TopCase key returned to support case dependency functions
Resolved in Pega Version 8.2.3
Case dependency was not working if the activity pxCheckFlowDependencies called the pzLoadCaseHierarchywrapper activity which further called the function pzMapCases to populate the pyTopCaseMap page. The page was loaded as expected when the 'when' rule pyEnableTopCaseLinks was false but when Top Case links were enabled, the page was not loaded appropriately. To handle this scenario, the system will return parent case key and class itself if it does not have a parent in pxGetTopLevelCoverKeyAndClass function.
SR-D24750 · Issue 501746
Resolved importing PublicFormat file using RuleFromFile Wizard
Resolved in Pega Version 8.2.3
When attempting to create a flow from a Public Format XML file using the Rule From File Wizard, the following error was seen: "Problem invoking function: pega_procom_harvest.performXSLT--(String,String,boolean,HashStringMap)". This was caused by a mapping failure related to the pyComments property in baseclass pega social functionality, and has been resolved with the addition of a new page group property pyComments of type "Data-MO-Annotation-Comment" which applies to "Embed-Rule-Obj-Flow-ProcessModel".
SR-D30505 · Issue 501895
Revalidate and save works for Service Packages using OAuth2.0
Resolved in Pega Version 8.2.3
Revalidate and Save was failing for service packages of type Data-Admin-ServicePackage which used authentication type as OAuth2.0 . If this was modified to basic authentication / unchecking authentication, revalidate and save was successful. Historically, the implementation of pzOnlyRestServiceType always assumed the primary page was the Service Package rule itself. To support this alternate use, the logic has been updated and a check of the Service Type has been added for the pxResults of the data page.
SR-D22468 · Issue 502036
Bix extract performance improved by only checking cipher type for encrypted properties
Resolved in Pega Version 8.2.3
Previously, if no cipher was configured in extract Rules the cipher type defaulted to null and wasn't cached. This caused performance issues when running against the database. In order to improve performance, the code has been modified to only check for cipher type if the property is encrypted.
SR-D28538 · Issue 502057
Corrected requestor status flag for direct map
Resolved in Pega Version 8.2.3
Numerous "Unable to create requestor" alerts were logged. This was traced to an error in HttpAPI where after retrieving the requestor from the internal requestor map directly, the requestor creation status flag was not set properly. This caused last action to post that alert instead of the correct notice of "existing requestor retrieved". This has been resolved so the flag reflects the correct status.