The initialization and configuration of a Content Section is controlled by com.arsdigita.cms.installer.SectionInitializer in enterprise.init. In order to create more than one Content Section, a separate SectionInitializer entry is required for each section created. Most SectionInitializer entries are one-time load parameters, so changing them after initial loading will have no effect. There are a few SectionInitializer parameters which serve as initialization upon startup. For these parameters, subsequent modification will cause changes to take effect upon the next server startup. Valid SectionInitializer parameters are as follows:
The name (and URL) of the Content Section. This parameter must be a valid keyword (alpha-numeric characters, underscores, and hyphens).
A list of roles for the Content Section. Each item in the list is itself a list with the following fields:
Role Name
Description
List of privileges
Workflow task to assign to (optional)
Example 6-1 is taken from the default SectionInitializer roles entry.
This entry is now empty, as content types are loaded in separate packages.
List of XML files which contain category trees.
Whether to make content viewable to 'The Public', i.e. non-registered users.
A list of lists. Each entry is a list which has a workflow task name as its first entry, and a list of action types for its second entry. The list of action types specify when alerts will be sent for a given workflow task name. Example 6-2 is taken from the default SectionInitializer taskAlerts entry. This parameter is initialized upon each server restart.
Should we send alerts about overdue tasks at all? This parameter is initialized upon each server restart.
The time between when a task is enabled, i.e., when it is made available for completion, and when it is considered overdue (in hours). This parameter is initialized upon each server restart.
The time to wait between sending successive alerts on the same overdue task (in hours). This parameter is initialized upon each server restart.
The maximum number of alerts to send about any one overdue task. This parameter is initialized upon each server restart.
// List of roles to create. First field is role name,
// second is the description, third is a list of
// privileges, and (optional) fourth is the workflow
// task to assign to
roles = {
{
"Author", "Creates new content",
{ "new_item", "read_item", "preview_item", "edit_item",
"categorize_items" },
"Authoring"
},
{
"Editor", "Approves the author's work",
{ "edit_item", "new_item", "delete_item",
"read_item", "preview_item", "categorize_items" },
"Approval"
},
{
"Publisher", "Deploys the content to the web site",
{ "edit_item", "new_item", "delete_item",
"publish", "read_item", "preview_item", "categorize_items" },
"Publishing"
},
{
"Manager", "Manages the overall content section",
{ "delete_item", "edit_item", "new_item",
"staff_admin", "content_type_admin", "lifecycle_admin",
"workflow_admin", "category_admin", "publish",
"read_item", "preview_item", "categorize_items" }
// NB, manager doesn't have any assigned task for workflow
}
}; |
Example 6-1. Typical section roles initialization
// 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" }
}
}; |
Example 6-2. Typical section alerts initialization