(For more resources on Plone, see here.)

Content rules

Plone features a usability layer around Zope’s event system, allowing plain users to create rules tied to the most used event handlers. These rules are composed of tasks that get triggered when an event is raised in our site. Content rules are defined site-wide in the Content rules configlet, and they are available for use in any folderish object in our site. Once the rule is created, it can be locally assigned to any folder object in the site.

Rules play a very important role in intranets. We can use them as a mechanism for notification, and they also help in adding dynamism to our intranet. One of the most demanded features in an intranet is the ability to be aware when content is added, changed, or even deleted. The notification of this change to the users can be achieved via content rules assigned strategically, or by user demand in any folder or intranet application, such as forums or in a blog.

We can use content types to help us model some of our corporate processes or daily tasks. Move or copy objects to other folders (done by users), just in case some of our processes require this kind of an action. We can find other interesting uses of content rules in our intranet, such as executing an action when a state transition is triggered.

All these actions can be carried out programmatically, but the power of content rules lie in that they can be executed thorough the Plone UI and by any experienced user.

We can access the manage rules form via the Rules tab in any folder. If we don’t have any rules created, the form will address us to create them in the content rules configlet. This control panel configlet will aid us to create and manage content rules of our site:

The form is divided into two parts. The first is dedicated to global settings applied to all rules. In this version, there is only one setting in this category to enable and disable the rules in the whole site. If deselected, the whole rule system is disabled and no rules will be executed in the site.

The other part of the form is reserved for the rule management interface. Here we can find the already created rules, manage them, and create new ones. We can display them by type using the selector on the right.

Adding a new rule

Click on the Add content rule button. It will open a new form with the following fields:

• Title: Title of the rule.
• Description: Summary of the rule.
• Triggering event: Starts the execution of the rule.
• Enabled: Whether or not this rule is enabled.
• Stop executing rules: Defines if the engine should continue the execution of other rules. It is useful if we assign several rules to a container and the execution of a particular rule excludes any other rule execution.

By default, these are the available events:

• Object added to this container
• Object modified
• Object removed from this container
• Workflow state changed

After creating one rule at least, the configlet will let us manage the existing rules, allowing us to perform the standard edit, delete, enable, and disable actions. But this is only the first step. We’ve created the rule and assigned an event to it. Now it’s time to configure the task, which the rule will perform. There are two items to configure—conditions and actions.

We can add as many conditions as we want to, and modify the order in which they can be applied. We can add the following types of conditions:

• Content type: Apply the rule only if an object of this type has triggered the event
• File extension: Execute the action only if a file content type that has this extension has triggered the event
• Workflow state: Apply only if a content type in the workflow state specified has triggered the event
• User’s group: Execute only if a user member of a specific group triggers the event
• User’s role: Same as User’s group, but by a user having a specific role in that context

The actions that a rule can execute are limited but they cover the most useful use cases:

• Logger: Output a message to the message system log
• Notify user: Notify the user via a status message
• Copy to folder: The object that triggers the event is copied to the specified folder
• Move to folder: The object that triggers the event is moved to the specified folder
• Delete object: The object that triggers the event is deleted
• Transition workflow state: An attempt to change workflow of the object that triggers the event via the specified transition
• Send e-mail: Send e-mail to a specific user

By default, only managers can define and apply new content rules, but we can allow more user roles to access their creation.

Assigning rules to folderish objects

Once the rule is created, we can assign them to any of Plone’s folderish content types. Just go to any folderish object and click on the Rules tab.

Just use the drop-down box Assign rule here to choose from the available rules and click on Add. We can review what rules are assigned in this container and manage them as well. We can enable, disable, and choose whether to apply them to subfolders or only to current folders, and of course, unassign them.

Making any content type rule aware

All folderish default content types of Plone are content rule aware. However, not all third-party content types are content rule aware. This is because either they are old or simply do not enable this feature in the content type declaration.

In the case of third-party content types, which are not content rule aware, we can enable their awareness by following these instructions: Add an object of the desired content type anywhere in our site, if we haven’t created it yet. Find it in the ZMI and access the Interfaces tab. Once there, find the interface plone.contentrules. engine.interfaces.IRuleAssignable in the Available marker interfaces fieldset. Select it and click on the Add button. By doing so, we are assigning an additional marker interface to that content type, which will enable (mark) this instance of the content type (that is, make it aware of the content rule). From this moment onwards, the selected object will have available the Rules tab, and in consequence, we can assign rules to it.

Syndication

Plone has always paid special attention to syndication, making its folderish content types syndicable. Collections export their contents automatically in a view that all collections have—RSS view. But we can also enable syndication for single folders on our site.

Using RSS feeds in our intranet is the recommended approach for keeping our users posted about the changes in syndicated folders, if they are collections or plain folders.

Enabling folder syndication

For enabling syndication for a particular folder, we need to access the view, synPropertiesForm, from the folder we want to be syndicable. For example, if we want to access this view in the ITStaff folder, we should browse the URL: http://localhost:8080/intranet/ITStaff/synPropertiesForm

This view is hidden by default, although we can make it visible in order to allow users to enable folder syndication by themselves. We can make it visible by accessing the portal_actions tool in the ZMI. Go to the object action category and choose syndication. Then just make this action visible by enabling the Visible attribute and choose who will be able to access this view by selecting the item permissions in the Permissions selection box.

Once in the synPropertiesForm form, we should click on the Enable syndication button. Then another form is shown to allow us to configure how the publication of the feed will be performed. Following are the syndication details available:

• Update period: How often the feed will be updated
• Update frequency: How many times the update will occur inside the period specified in the previous field
• Update base: When the update will take place
• Maximum items: How many items the feed will show

Accessing a secure RSS feed

Syndication was conceived to access information from public resources. Inside an intranet, it will be very common that the folder we want to enable for syndication will be not published, and in consequence, the feed associated will be private. The problem is that there are few feed readers that support feed authentication and even using them. We will have to enable HTTP authentication in our site’s PAS configuration, which is not recommended. So we propose two workarounds.

We can use a feed enabled browser to browse our intranet and our feeds as well. With this approach, if we are logged in, then we will have access to authenticated feeds. Firefox and Internet Explorer already have this feature.

The second approach is to have a special workflow state for the syndicated folders inside our site for being accessible without authentication as anonymous users. Obviously this workaround will make the folder content visible to anonymous users, and it’s not an option when privacy of the contained information is a must.