SR-D42402 · Issue 508896
Added differentiated handling for special symbols based on location in the label string
Resolved in Pega Version 8.4
While importing an Excel file into a decision table that used custom functions like@string:notequal or equal, label names like 'AlphaPrefix !=AAA' resulted in the error "invalid expression or reference: line 1:28 extraneous input '"True"' expecting {<EOF>, '-', '+', '=', '*', '/'," " . Investigation found that the problem was with the label of the column not handling the the special characters like (‘!=’, ‘<’ , ‘<=’, ‘>’, ‘>=’ ) present in the middle of the label string: the label and default operator were being updated irrespective of the location of the symbols within the string. To resolve this, DecisionTableWorkBookConverter.java has been modified to set the operator only if the special strings (‘!=’, ‘<’ , ‘<=’, ‘>’, ‘>=’ ) are present at the end of the label.
SR-D42402 · Issue 508895
Added differentiated handling for special symbols based on location in the label string
Resolved in Pega Version 8.2.4
While importing an Excel file into a decision table that used custom functions like@string:notequal or equal, label names like 'AlphaPrefix !=AAA' resulted in the error "invalid expression or reference: line 1:28 extraneous input '"True"' expecting {<EOF>, '-', '+', '=', '*', '/'," " . Investigation found that the problem was with the label of the column not handling the the special characters like (‘!=’, ‘<’ , ‘<=’, ‘>’, ‘>=’ ) present in the middle of the label string: the label and default operator were being updated irrespective of the location of the symbols within the string. To resolve this, DecisionTableWorkBookConverter.java has been modified to set the operator only if the special strings (‘!=’, ‘<’ , ‘<=’, ‘>’, ‘>=’ ) are present at the end of the label.
SR-D42402 · Issue 508894
Added differentiated handling for special symbols based on location in the label string
Resolved in Pega Version 8.3.1
While importing an Excel file into a decision table that used custom functions like@string:notequal or equal, label names like 'AlphaPrefix !=AAA' resulted in the error "invalid expression or reference: line 1:28 extraneous input '"True"' expecting {<EOF>, '-', '+', '=', '*', '/'," " . Investigation found that the problem was with the label of the column not handling the the special characters like (‘!=’, ‘<’ , ‘<=’, ‘>’, ‘>=’ ) present in the middle of the label string: the label and default operator were being updated irrespective of the location of the symbols within the string. To resolve this, DecisionTableWorkBookConverter.java has been modified to set the operator only if the special strings (‘!=’, ‘<’ , ‘<=’, ‘>’, ‘>=’ ) are present at the end of the label.
SR-A9225 · Issue 222951
Long word break added to SMA tables
Resolved in Pega Version 7.2
In Microsoft Internet Explorer 11, the SMA system management screen (the screen right after login) would sometimes not display the relevant fields in the tables until the horizontal scrollbar was moved all the way to the right. This was different behavior than with other versions of Microsoft Internet Explorer , and occurred when the content of a table-cell included a very long value without any word break. In this case, current style control could not break the long wording out to pieces, resulting in it crossing over the whole screen until the word was displayed. This was a cosmetic issue that did not influence operations, but style control has been added to enforce long word break in these cases.
SR-A99969 · Issue 266109
Ruleset listing works without enabling UDFs
Resolved in Pega Version 7.2.2
All core Designer Studio features and Pega frameworks / applications are supposed to work without dependency on pr_read* UDFs, but an issue was found with attempting to list rulesets without enabling UDFs. This was due to the Designer Studio features used to list instances of a rule class performing behind the scenes filtering to exclude rules with pyMethodStatus = Internal pr Deprecated. Listing members of rule-ruleset-name then failed as this class does not have an exposed property pyMethodStatus. To fix this issue, a check has been added to decide if the rule type is rule resolved or not. If the rule is resolved, then there will be a check for pyMethodStatus exposed or not. If pyMethodStatus is not exposed, then it will fallback to old list view. In addition, a check was added to not to add filter conditions on pyMethodStatus for non-rule resolved rule types. The only exception to this is Rule-Utility-Library, i.e. even though library ruleform is non rule resolved, pyMethodStatus filter will be added.