Published Release Notes

Change logic does not work in Report Editor

The Report Editor​ change logic button does not work. As a workaround, use the rule form to change the logic.

Tomcat log files moved to work directory

For Tomcat application server users, the default path for PRPC logs has been changed to the "work" directory for Catalina. For example:

<tomcat>\work\Catalina\localhost\prweb

This directory can be cleaned up during administration. To avoid loss of files, you can redirect logging to a different directory after installation:

1. Navigate to the <tomcat-home>\webapps\prweb\WEB-INF\classes directory.
2. Open the prlogging.xml file.
3. Locate the "appender" definitions section that contains the "@{web.tmpdir}" string
4. Update the FileNamePattern values to point to the new directory.

For more details, refer to the “Change the default path to PRPC logs” section in the Tomcat installation guide for your database.

Slow WebSphere performance on Mac platforms

Use the following JVM setting to improve WebSphere performance on Mac platforms:

-Djava.net.preferIPv4Stack=true

Split schema systems require additional privileges

On Oracle split schema systems, add the following database privileges:

• Grant DROP ANY INDEX to the Admin User.
• Grant UNLIMITED TABLESPACE to the Rules User.

Use the Oracle Enterprise Manager to add these privileges or refer to the 7.1.3 Upgrade and Installation guides for Oracle.

Data schema error on z/OS split schema upgrades from versions before Pega 7.1.8

When upgrading to a split schema on Pega 7.x with IBM DB2 for z/OS, you see an error during the data schema upgrade when the system tries to drop the PRPC_Updatescache procedure. Because triggers on rules tables use PRPC_Updatescache, you must use the ZOSDisableTriggerScripts to disable these triggers before you update the data schema.

1. Follow the instructions in the Pega 7 Platform Upgrade Guide to upgrade the rules schema, but stop immediately before you upgrade the data schema with the upgrade.bat or upgrade.sh script. The Pega 7 Platform Upgrade Guide is on the Support > Deployment Guides page.
2. Copy the contents of the <distribution>\ResourceKit\ZOSDisableTriggerScripts directory into the <distribution>\scripts\ directory.
3. Run fixZosTriggers.bat or fixZosTriggers.sh with the following arguments:
   --action preupgrade
--dataschema <data schema name>
   --oldrulesschema <old rules schema name. If you are upgrading from a single-schema system, this is the data schema name.>
   --newrulesschema <new rules schema name>
   --automaticddl <Optional. Set to true to automatically apply the disable trigger SQL scripts.>

   For example:
   fixZosTriggers --action preupgrade --dataschema pegadata --oldrulesschema pegarules --newrulesschema newrules --automaticddl false

4. If you did not set --automaticddl to true in the previous step, run the <distribution>\schema/disable.sql script to manually disable the trigger SQL scripts.
5. Run the data schema upgrade as described in the Pega 7 Platform Upgrade Guide.

Application Express and the Content Security Policy

Application Express copies (if defined) the Content Security Policy (CSP) name (pyContentSecurityPolicyName) from the built-on application in a new application. It also sets the CSP mode (pyContentSecurityPolicyMode) to report. The values appear in the Content Security area on the application rule's Integration & Security tab.

When checking an application in the DCO Compatibility tool, a warning appears if the CSP name is missing.

Certain flow actions deprecated and replaced

To ensure compatibility with supported browsers and mobile devices and to enhance ease of design, the following flow actions are deprecated and replaced. As a best practice, use the replacement actions for new development. The deprecated rules are still supported and do not have to be updated.

For example, the new Transfer Assignment action supports the most common routing options such as operator, workbasket, and reporting manager. Advanced options allow users to escalate, set due dates, update status, and provide instructions.

Transform Assignment form

See Atlas - Standard Flow Actions (Local)​.

Service levels are available on stage steps

For greater flexibility when configuring stages, you can associate a service level (SLA) with a step within the context of the stage only. Because this SLA overrides the one associated (if defined) with a a step, other steps that employ the same flow are not affected and can be configured independently.

See Using the Stages & Processes tab.

Managers can create and update cases using the Bulk Actions tool

The capabilities of the Bulk Actions tool have been expanded so that managers can go beyond simply being able to make bulk updates to existing cases. They can now:

• Create top-level cases for any case type in your application. By default, you can specify the label, description, and work status for each case.
• Define the case information you want to display on the grid by overriding the section pyBulkUpdate and configuring the columns.
• Update the case information you created in the Bulk Actions tool.

Create Cases option in the Bulk Actions tool

See Case Manager Portal — How to process assignments and cases in bulk.

Define distinct names to implementation and framework class layers in Application Express

When generating both implementation and framework applications in Application Express, you can now name the framework application and workpool class layers independently. This eliminates the need to update a framework's class structure in the new application. Previously, the framework layers used the same names as the implementation and could not be updated.

​

Class structure name fields in Advanced Configuration dialog

See Application Express — Advanced Configuration.