Red Hat Content Management System 6.1: CMS Deployment Guide
PrevChapter 5. Configuration GuideNext

5.5. Customizing Workflow Notification Alerts

Workflow alerts are dependent on the workflow, notification, and mail services. You must have those services properly installed and configured prior to activating workflow alerts.

You can configure the CMS to send email alerts to workflow participants when a content item's workflow task changes state. Alerts are sent when the task starts, ends, is disabled or is rolled back. Each Content Section defines which alerts it sends on a state change for each of the three task types: Author, Edit, and Deploy. Although the default workflow task names reflect the same naming scheme, there can be as many workflows as you want to create, while there are only three task types.

The default Content Section has three default workflows, Authoring, Approval, and Deploy. The Content Section is configured to send alerts when a task starts, ends, or is rolled back for each of the three task types.

The email alerts describe to recipients the state that has either been started or completed, the name of the content item the task was performed on, the name of the person who triggered the task start or completion, the latest comment on the workflow task, and a link back to a page in the CMS where the recipients can begin their own task.

5.5.1. Workflow Alert Configuration

Workflow alerts are configured in enterprise.init through four Initializers:

The taskAlerts parameter mapping in SectionInitializer defines which of the four task states will trigger an alert for each of the three task types.

Here is the default SectionIntializer configuration: 

// When to generate email alerts: by default, generate email alerts
// on enable, finish, and rollback (happens on rejection)
// changes. There are four action types for each task type: enable,
// disable, finish, and rollback. Note that the values below are
// based on the task labels, and as such are not globalized.
 taskAlerts = {
   { "Authoring",
     { "enable", "finish", "rollback" }
   },
   { "Approval",
     { "enable", "finish", "rollback" }
   },
   { "Deploy",
     { "enable", "finish", "rollback" }
   }
 };

CautionCaution
 

The SectionInitializer settings are set only one time at the first system start up. There is currently no easy way to change the taskAlerts parameter settings once a Content Section is installed. Be sure of your settings before your initial system start up.

The remaining three Initializers contain global settings used by all Content Section workflow alerts.

The com.arsdigita.workflow.simple.Initializer contains parameters for you to specify the sender address for the workflow alert email, the sender's given (first) name, and the sender's family (last) name.

One parameter not controlled via enterprise.init is sendAlerts, which instead is controlled via the parameter system at waf.workflow.simple.alerts_enabled=true/false. It acts like a switch for turning on or off workflow alerts in all Content Sections. By default, this parameter is set to false (off). Set the sendAlerts parameter to true (on) to activate workflow alerts.

com.arsdigita.notification.Initializer contains settings that affect how quickly workflow alert emails are sent to recipients. New workflow alerts are first stored as notifications in the system for further processing. At this point no emails have been sent. A RequestManager daemon in turn processes the notifications by adding them to the SimpleQueueManager processing queue. If a workflow alert is addressed to a group, the RequestManager queues up an email for each group member. A second daemon, the SimpleQueueManager, reads its queue, creates emails and finally sends the email.

You can configure when the RequestManager and the SimpleQueueManager begin processing after the system starts up by changing the RequestManagerDelay and SimpleQueueDelay parameters in com.arsdigita.notification.Initializer. You can also configure how often the both daemons run by changing the RequestManagerPeriod and SimpleQueuePeriod parameters.

You will need to verify that the parameters for configuring the SMTP server are correct. These parameters are found in com.arsdigita.mail.Initializer.

NoteNote
 

The debug flag has moved from com.arsdigita.mail.Initializer to the new parameter system at waf.mail.debug=true/false.

5.5.2. How to Customize Alert Emails

The subject and body of all workflow alert emails are defined in CMSReources.properties. This file is located under the src/com/arsdigita/cms/ui/ of the CMS application or under the /ccm/WEB-INF/classes/com/arsdigita/cms/ui directory of your webapps directory.

Toward the end of the CMSResources.properties file you will find the subjects for each of the four task states:

In the file you will also find the bodies for each of the four task states as:

Substitutions for the item title, authoring page URL, site name, and many others are available for inclusion in the subject or the body. Please review the CMSResources.properties file for a complete list of substitutions.

5.5.3. Customizing Overdue Workflow Task Alerts

You can specify how long a task can remain incomplete before it is considered overdue in the parameter com.arsdigita.cms.installer.SectionInitializer. When a task is overdue the system can send alerts to workflow participants notifying them the task is awaiting their attention.

To adjust the details within these alerts, the system provides four parameters under com.arsdigita.cms.installer.SectionInitializer: sendOverdueAlerts, taskDuration, alertInterval, and maxAlerts. You may turn on or off these alerts by changing the sendOverdueAlerts parameter.

The taskDuration parameter specifies the time interval, which begins when a task is enabled and marks when it is considered overdue. The alertInterval parameter specifies the time interval between successive alerts on the same overdue task. The maxAlerts parameter specifies the maximum number of alerts the system may send for an overdue task.

Similar to the workflow notification alerts, you may customize the subject and body of the overdue workflow task alerts. The subject and body are defined in the file CMSResources.properties as cms.ui.workflow.email.subject.unfinished and cms.ui.workflow.email.body.unfinished.

5.5.4. Customizing Content Expiration Alerts

The CMS can send content expiration alert emails to members of the Alert Recipient role in each content section. The CMS automatically creates the Alert Recipient role for you when you create a new content section.

To enable the content expiration alert emails, you must set the following:

PrevHomeNext
Security SettingsUpImporting Data