(For more resources on Plone, see here.)
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.
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.
(For more resources on Plone, see here.)
Versioning has been around since Plone 3. It keeps track of all the changes made to an object by saving them as revisions. These changes can be compared; we can undo the changes made for a specific version and switch any previous version with the current one.
Nowadays it's hard to conceive a CMS without a version system. Versioning is more a requirement than a feature.
This feature used to live on an object tab called History, but since Plone 3.3 it was moved to the History collapsible menu at the bottom of the standard view. This is how it looks; a page with several changes and the History menu expanded:
The Change note field of any content type is a part of the versioning system and allows us to add a comment to any version before we submit the changes to the server, creating a new version. This comment is stored with the version and is useful as a description of the changes made to the object.
We can view what the page looks like in each version using the View this revision link. We can compare each of the previous versions with the current one, and comparison can be made between the previous versions as well. We can also revert to the version we desire by clicking on the corresponding button.
The comparisons are made using a form that shows us the differences between versions inline or as HTML code. We can also change the version number using the Versions selector. The differences of the object's metadata can be seen as well.
Changing versioning policy
We can change versioning policy by using Plone's control panel Types configlet. If we select one particular content type, we will find the Versioning policy drop-down box. There are three settings: automatic, manual, and no versioning.
There are several ZMI tools implied in the versioning system as well. It's interesting to show the functionality of two of them: portal_historiesstorage and portal_purgepolicy.
Inside the first one, we can find information about storage statistics from current versions in our site. We can check the following:
- Number of histories
- Number of versions
- Average versions per history
We can see the most versioned objects and their location too.
The number of versions stored is infinite by default. However, we can change the behavior of versioning from portal_purgepolicy by changing the default infinite value (-1) of the maximum number of versions to keep in the storage attribute to the desired value.
Recommended number of stored versions
It's expected to have a high profile of changes and modifications in a moderately crowded intranet. It's advisable to keep the number of versions to a sustainable value because it's related to the space occupied by the object in the database. Every version we create of any object is stored in the database and it never gets purged. Usually keeping ten versions for all objects is a good practice and enough for almost any use case.
Web-based Distributed Authoring and Versioning, or WebDAV, is a set of extensions to the Hypertext Transfer Protocol (HTTP) that allows computer-users to edit and manage files collaboratively on remote World Wide Web servers. RFC 4918 defines the extensions. It allows users to create, change, and move documents on a remote server (typically a web server or "web share"). WebDAV allows us to interact with our web content, as it was files and folders on our computer. We can literally mount a WebDAV folder as a folder on our computer's filesystem.
Nowadays, every major operating system has a client implementation of WebDAV and there are many third-party clients we can use. Windows Explorer, Nautilus, and Konqueror for Linux, and Finder for Mac OS X have a WebDAV client built in.
The implementation of WebDAV clients is not homogeneous out there. Every vendor has their own implementation and may slightly differ from others. These few differences can cause the interaction with our information to fail, so be careful about it. A test with our preferred client on the most common activities when dealing with WebDAV (copy, move, delete, rename) is highly recommended.
Any default, out-of-the-box Plone object is WebDAV aware and is accessible using its URL. The idea is that we can mount a WebDAV resource from any of these clients by using the object URL.
This is the complete set of instructions for Mac OS X:
- Open Finder, select Go menu, and then Connect to server... or press Command + K
- Specify the URL of the resource in the Server address field, for example, our site's root: http://localhost:8080/intranet and then click on Connect. We should be prompted for authentication.
After a few seconds, we will be able to see the entire site's structure as filesystem resources, via WebDAV:
We can perform the same operations on displayed items as they were files or folders in our filesystem. Copy, move, rename, and so on. If we have logged in as a manager, we should be able to see the content and site's tools as well. If logged in as a plain user, we will see the objects we are allowed to see depending on our permission rights.
The advantage in an intranet scenario is obvious. Having desktop client interaction with our intranet is a valuable companion and an inestimable feature. Our users can do massive file uploads, move and rename content, and even copy entire folders from the site right to their desktops.
Managing WebDAV access permissions
- WebDAV access
- Manage WebDAV Locks
- WebDAV Lock items
- WebDAV Unlock items
Use them to restrict or allow WebDAV access to our intranet resources. By default, only managers can access via WebDAV.
We can assign the desired roles to these permissions with a custom workflow, or set them globally by setting the proper role mapping in the rolemap.xml file of a GenericSetup profile in a custom add-on product.
When our users upload files to the intranet, eventually our users may want to modify these files. The standard procedure will be simple but tedious: download it, modify it locally with the associated software (let's say OpenOffice), save it locally, and upload again (modifying the original file object type), and save it.
Plone features the external edition to overcome all that. With the help of an external desktop application (External Editor), we can modify and save the file on the fly. This little Python application (of course) does all the dirty work for us. It opens the file via WebDAV, and launches the associated application in our computer with it. We can modify it, and when we save the file, automatically save it via WebDAV, modifying the original file on the server.
External Editor also manages a WebDAV lock, so nobody else could modify the object while we are editing it. When we close the application, the file is saved via WebDAV and the lock is released.
Since External Editor is Python-based, it is multiplatform, and can be run on any major platform. We can find the script (zopeedit.py) and a Windows packaged version in: http://plone.org/products/zope-externaleditor-client.
Installing the External Editor
Getting this tool installed in our computer involves two things: installing a Python script that takes care of the edition process, and the bindings with our default browser that instructs it to launch the script for a special MIME type (application/x-zope-edit).
Installing it in Windows is very straightforward: just run the .exe provided and External Editor will install it in our computer and will configure our default browser bindings.
Installing it in a Linux machine is more manual because the packages included in the official distros tend to be outdated. In case of UBUNTU, we can try this recipe as there is a .deb software package in the UBUNTU repositories, but it's not updated. However, we are going to use it as a base, as it will configure our browser's MIME types correctly:
$ sudo apt-get install zopeedit
Download the updated zopeedit.py file from the URL:
Overwrite the original one installed by the .deb package by copying the updated version we've just downloaded from our download folder to this path:
$ sudo cp zopeedit.py /usr/bin/zopeedit
After this, we will have the script updated and a ready-to-use External Editor when we enable it on our profile.
We should probably check out plone.org for the latest version of External Editor. At the time of writing, 0.9.11 was the last version available.
Mac OS X
We need to download the External Editor packaging for OSX from plone.org: http://plone.org/products/zopeeditmanager/releases/0.9.7/osx-installer. It's a Cocoa-based application for Mac OS X that implements an External Editor called ZopeEditManager.
Unzip the downloaded file (osx-installer.zip) and copy the application, ZopeEditManager, to our /Applications folder. Launch it like any other application. By default, it shows a window with the list of all the files being edited. ZopeEditManager provides a GUI Preferences panel. Just choose Preferences... from the ZopeEditManager menu. In this panel, we can adjust the helper applications, WebDAV properties, and other configuration.
Enabling external editing
Any user can enable external editing in his site profile. We can access it by clicking on our name's link on the personal toolbar and then clicking on Personal profile, or accessing the personalize_form view.
Mark the Enable external editing checkbox to enable external editing for our user and then save. When checked, a pencil icon will be visible on each page that allows us to edit content using an External Editor. When clicked, External Editor will launch the defined helper application with the specified file.
Modifying helper software
There are a number of MIME types associated with External Editor. However, we can change it and specify our preferred application to use with external edition. There is a configuration file located in our home called .zope-external-edit, in case of a Linux box, or in our Documents folder, in case of a Windows computer. We can adjust helper applications using the Preferences... panel in ZopeEditManager for Mac OS X.
In this article, we've learnt about the following advanced content features and how to take advantage of them.
- Content rules
- WebDAV access
- External edition
Don't hesitate to teach our intranet users about them; they will benefit a lot from it. The content in an intranet is not meant to be static; it should be dynamic as our users work with it and share information with each other. These tools will help them be more productive and efficient in this task.
- Building Websites with Plone [book]
- Professional Plone Development [book]
- Plone 3 Themes [article]
- Add-on Tools and Theming Tips for Plone 3 [article]
- Building our own Plone 3 Theme Add-on Product [article]