INC-123033 · Issue 561388
Updated logic for delegating when the RARO exists
Resolved in Pega Version 8.4.2
When trying to delegate a Data Type, the validation error "Update Record Failed: This record is non-versioned and already exists and can not be moved to a different ruleset" appeared. Because data type delegation is dependent upon the existence of a RARO for the delegated data type, when delegating the ruleset of the RARO to accessgroups with the same roles the code was attempting to update the RARO. Updating the RARO determines if the Ruleset of the RARO is unlocked. If the ruleset is locked, then the logic attempts to select a new ruleset, but the RARO cannot be moved to a new ruleset. To resolve this, the logic has been updated so that if the RARO exists, the system will not try to create a new instance.
SR-D93112 · Issue 554909
Added backwards compatibility for migrated when rules
Resolved in Pega Version 8.4.2
After upgrading from v6 to v8, the 'when' rules were replaced with "" in a custom decision tree. In 7.2 and earlier releases, the Rule-Obj-When function alias had its param name as "strName"; this was changed to "blockName" in later versions of Pega. To handle backwards compatibility, the pzEmbedUpgradeToHarnessBased activity has been modified to read the strWhen param value from pyCallParams and set it to blockName params correctly under pyFunctionData.pyParameters data model, conditionally only for Rule-Obj-When function alias.
SR-D39547 · Issue 505859
Check added for backwards compatibility with Case Type when rules
Resolved in Pega Version 8.1.7
After upgrade, the When rules present on case type rules (used for skipping stages or showing/hiding stage-wide or case-wide actions) were not executing at run time. This was traced to the introduction of the pySkipOrAllowType property in recent versions, and was only reproducible when the ApplicationRuleset was locked and after upgrade irrespective of whether the condition for when was true or false. To resolve this and enhance backwards capability, a check has been added for the SkipOrAllowType property being empty.
SR-D76492 · Issue 549970
Added check for test case creation when Cross-site scripting security enabled
Resolved in Pega Version 8.4.2
Test case creation was failing. Investigation showed that when the "Cross-Site Request Forgery" security setting was enabled, the CSRF token and Browser fingerprint were not included in AJAX calls, and the Ruleinskey was not getting passed. This has been resolved by adding a check to evaluate whether security measures are included or not when making a server call from AJAX, and including the tokens required when appropriate.
SR-D95797 · Issue 556765
Branch Preference now considered for TestCase rule
Resolved in Pega Version 8.4.2
Setting branch preference from top right worked for all rule types and new rule dialog rightly set the branch, but when attempting to use this configuration for a test case, it only displayed the first branch in the app and did not follow the branch preference. This was due to the system using a separate save modal dialog for test case creation which did not consider this use, and has been resolved by implementing the branch preferences use case to show the direct preferred branch if present.
INC-120450 · Issue 561743
Configure view finds existing calculations for properties
Resolved in Pega Version 8.4.2
Modifying a property to ‘calculated: Readonly’ by creating declare expression inside a fieldgroup list (which was created in the data model and refers to a datatype) while adding the fieldgroup list property by selecting from the field in the configure view of a step was not reflected when adding the same list type property inside another step of configure view. Declare expressions were created with page context for embedded fields by default in configure view, but Declare expressions have recently been enhanced and no longer expected to use page contexts. Because Configure view continued to use page contexts, this resulted in calculations that existed not being picked up. This has been resolved by configuring view handling for page list fields specifically to not create new calculations with a page context. Detection of calculations has also been updated to not check for page context to match the recent Declare expression enhancements.
INC-125706 · Issue 565518
Expression Builder test functionality updated to improve context resolution
Resolved in Pega Version 8.4.2
After upgrade, running a test in Expression Builder to evaluate an expression resulted in a 'Property undefined' error. Although the test functionality failed, the data transform rule was properly saved and no issues were observed at runtime. This was traced to a change made in the way the IDs on input elements were made unique. This caused an issue with Expression Builder resolving the correct context when the Source property page was not the primary page class, such as in these cases:1) For Each Page with the "Also use each page as source context" checkbox checked 2) Update page using the "with values from" 3) Append and Map to with "an existing page" 4) Append and Map to with "each page in" To resolve this, the pzEBHiddenElement function has been updated.
SR-D91834 · Issue 554426
Related cases of different types properly linked in Case Worker Portal
Resolved in Pega Version 8.4.2
After creating a case of type1 in the Case Worker portal, creating a case of type2 from the first case showed the case ID of the second case in the Related Work section as expected. However, after clicking on the link of the case ID of the second case from the related work section, the second case opened but the case ID of the first case was not shown in the Related work. The cases were correctly associated when the Case Manager portal was used instead. This was traced to the Case Worker clipboard continuing to hold the previous case ID thread, and has been resolved.
INC-133213 · Issue 572534
Merge group size decreased to match SQL list limits
Resolved in Pega Version 8.4.2
Duplicate rules were seen and the error "maximum number of expressions in a list is 1000" was generated after performing a ProvAuditFW merge. Before merge there was a property populated with a comma-separated list of instances to be merged: this was used later as the source of a report definition. This was presented as a value list because of the limitations of datapages to accept very large 'when' clauses. This comma separated list was split up into batches of 200 to keep the length of this 'where' clause low. However, the SQL that was generated exceeded the limit of 1000 items in a list, causing the error and duplicates. To resolve this, the group size has been decreased so that limit will not be hit.
INC-78420 · Issue 566792
Documentation clarified for pxGenerateExcelFile with template values
Resolved in Pega Version 8.4.2
Using Export to Excel created the document, but pxGenerateExcelFile was not replacing template values in the generated output file. To improve the clarity of the necessary configuration, the documentation for pxGenerateExcelFile has been updated to include an example of the usage:This can be used anywhere in platform to export excel file. E.g. - export stories, specifications, requirements etc. Example Usage of properties in template: {.pagelist().property input}\n{.property input}