SR-116508 · Issue 170253
Large flow handling improved for IE8
Resolved in Pega Version 7.1.7
When opening a large flow in IE8 which includes multiple sub flows, a long-running script warning is displayed. This is caused by too many calls being executed at once on IE8, and has been remedied by turning on the asyncProcessing parameter for IE8.
SR-116818 · Issue 167121
Corrected swim lane routing with shapes
Resolved in Pega Version 7.1.7
While using swim lanes, adding shapes into the flow caused unexpected and random behavior of the process modeler including failure to return control to the user after saving. This error was related to routing handling when swim lanes are present, and has been corrected.
SR-117228 · Issue 168249
Resolved issues with Flow shapes distributed across Swim Lanes
Resolved in Pega Version 7.1.7
Pool size is maintained as both pixels and inches, but auto conversion was failing if the pool dimension was very large. This created an error where saving a flow rule could cause the pool to drastically shrink (for example, 20 inches becoming 20 pixels). In order to maintain the proper dimensions, a check has been added for pool and swimlane to ensure the proper inch/pixel conversions.
SR-133183 · Issue 205535
Fixed flow line distortion in Process Modeler
Resolved in Pega Version 7.1.9
When clicking through to a subprocess from a parent flow (by clicking the + sign in the blue subprocess shape), flow lines in the subprocess were shown in a distorted fashion. When opening the same flow in a separate tab (by right clicking the blue subprocess shape and selecting Open Flow) the flow lines were correctly painted. This was an issue caused by the different renderings of the flow depending on whether there was a click through to it (with the + on the parent flow?s subprocess shape), or the subflow was opened in a separate tab (with open Flow). After the Process Modeler saved and checked-in the flow, the connector lines were re-drawn in ways that were non-intuitive and hard to interpret due to the edge routing in PM being calculated off incorrect input data that was taking into account shapes that were not represented on the screen. To fix this, the system now ensures the edges are routed without taking into account any shapes not represented on the canvas.
SR-133184 · Issue 203710
Fixed flow line distortion in Process Modeler
Resolved in Pega Version 7.1.9
When clicking through to a subprocess from a parent flow (by clicking the + sign in the blue subprocess shape), flow lines in the subprocess were shown in a distorted fashion. When opening the same flow in a separate tab (by right clicking the blue subprocess shape and selecting Open Flow) the flow lines were correctly painted. This was an issue caused by the different renderings of the flow depending on whether there was a click through to it (with the + on the parent flow?s subprocess shape), or the subflow was opened in a separate tab (with open Flow). After the Process Modeler saved and checked-in the flow, the connector lines were re-drawn in ways that were non-intuitive and hard to interpret due to the edge routing in PM being calculated off incorrect input data that was taking into account shapes that were not represented on the screen. To fix this, the system now ensures the edges are routed without taking into account any shapes not represented on the canvas.
SR-A1705 · Issue 205449
Fixed scrumboard intermittent failure
Resolved in Pega Version 7.1.9
After upgrading, it was seen that the scrumboard would intermittently fail to load, partially displaying and then hanging if the columns did not fit within the window boundaries due to the number of elements. This was traced to an error in the functionality that resizes parts of the scrumboard, and has been fixed.
SR-A4995 · Issue 213355
Fixed flow line distortion in Process Modeler
Resolved in Pega Version 7.1.9
When clicking through to a subprocess from a parent flow (by clicking the + sign in the blue subprocess shape), flow lines in the subprocess were shown in a distorted fashion. When opening the same flow in a separate tab (by right clicking the blue subprocess shape and selecting Open Flow) the flow lines were correctly painted. This was an issue caused by the different renderings of the flow depending on whether there was a click through to it (with the + on the parent flow?s subprocess shape), or the subflow was opened in a separate tab (with open Flow). After the Process Modeler saved and checked-in the flow, the connector lines were re-drawn in ways that were non-intuitive and hard to interpret due to the edge routing in PM being calculated off incorrect input data that was taking into account shapes that were not represented on the screen. To fix this, the system now ensures the edges are routed without taking into account any shapes not represented on the canvas.
INC-203994 · Issue 698853
DSS added to handle merges with lower versions of Postgres
Resolved in Pega Version 8.7.1
After update, executing the batch campaign with volume constraint resulted in the second data flow DF_Wait failing with error message "ERROR: number of columns (1844) exceeds limit (1664)". This was due to the database set’s change (in 8.5) to use the database layer’s merge statement. Prior to that, the logic used "deletes and inserts". Depending on the version of Postsgres, the generated SQL statement for a merge statement is different. The “INSERT … ON CONFLICT … UPDATE” syntax is generated for Postgres 9.5+ AND when there is a PK constraint defined for the DB table. Otherwise, the complex UPSERT statement (old syntax) is generated, as was the case in this issue. This is a known issue in the Postgres server software where it mis-interprets the number of columns involved. i.e., it mistakenly counts the number of columns twice. As a result, the actual maximum columns allowed is only half of the official limit (1664). The same UPSERT statement does not cause the “exceeds limit” exception if there are 832 or fewer columns in the statement. To resolve this, an option has been provided to select between the “original logic” (deletes and inserts) and the “merge statements” logic by way of the DSS “decision/datasets/db/useMergeStatementForUpdates”. Setting “true” will use the merge statement logic, and setting “false” will use deletes and inserts. When the DSS is not defined, the default is "true" and the system will use merge statements in the form preferred by Postgres 9.5+.
INC-180246 · Issue 699700
Support for apostrophe added to keyword tokenization
Resolved in Pega Version 8.7.1
A keyword containing an apostrophe was not detected properly in Text extraction model. This has been resolved by updating the annotator used in the tokenization.
INC-193399 · Issue 688115
DSS added to handle merges with lower versions of Postgres
Resolved in Pega Version 8.7.1
After update, executing the batch campaign with volume constraint resulted in the second data flow DF_Wait failing with error message "ERROR: number of columns (1844) exceeds limit (1664)". This was due to the database set’s change (in 8.5) to use the database layer’s merge statement. Prior to that, the logic used "deletes and inserts". Depending on the version of Postsgres, the generated SQL statement for a merge statement is different. The “INSERT … ON CONFLICT … UPDATE” syntax is generated for Postgres 9.5+ AND when there is a PK constraint defined for the DB table. Otherwise, the complex UPSERT statement (old syntax) is generated, as was the case in this issue. This is a known issue in the Postgres server software where it mis-interprets the number of columns involved. i.e., it mistakenly counts the number of columns twice. As a result, the actual maximum columns allowed is only half of the official limit (1664). The same UPSERT statement does not cause the “exceeds limit” exception if there are 832 or fewer columns in the statement. To resolve this, an option has been provided to select between the “original logic” (deletes and inserts) and the “merge statements” logic by way of the DSS “decision/datasets/db/useMergeStatementForUpdates”. Setting “true” will use the merge statement logic, and setting “false” will use deletes and inserts. When the DSS is not defined, the default is "true" and the system will use merge statements in the form preferred by Postgres 9.5+.