Keep track of what's happening on your Web site with alerts for key events.
Last month, we started to look into the powerful open-source Bricolage content management system (CMS) written by David Wheeler and based on mod_perl, HTML::Mason and PostgreSQL. Content management software is a relatively new type of Web application, designed to make it possible to manage large Web sites. Bricolage has been widely hailed as a new open-source success story, demonstrating that proprietary software is not necessarily more flexible or more powerful than its free software counterparts.
It's important to remember that although a CMS is a Web-based application that depends on dynamically generated server-side programs, the output from a CMS typically is a static site. So even though Bricolage is a large Web/database program and customizing Bricolage requires server-side programming skills, it actually is an application meant to be used on a day-to-day basis by nonprogrammers. Indeed, organizations from Salon.com to MacWorld on-line currently use Bricolage. And thousands of other Web sites, from CNet to LinuxJournal.com, use content management solutions ranging from Vignette (complex, proprietary and expensive) to PHPNuke (simple, open source and free of charge).
This month, we look at one of my favorite Bricolage features, alerts, which allow users to keep track of different activities on a Bricolage system. Not only do alerts keep us informed of what is happening, they also provide a good way to see how the system works—by looking at the list of objects, by the actions that can be taken on each of those objects and by knowing when the alerts actually are triggered.
Bricolage, like most CMS software, moves articles through stations in a pipeline. In Bricolage, these stations are known as desks, reflecting the software's origins in the world of journalism. Stories thus begin at the edit desk, move to the copy desk, then to the legal desk and finally to the publish desk, from which they actually can be published on the Web.
On a small Web site being managed by only a handful of people, it is easy to keep track of which articles are kept where. But once you get beyond a small number of people or a small number of articles, it becomes difficult to keep track of what is happening with each article.
One way to handle this work flow is to look at the various desks, one at a time, to see what stories are on each one and then take appropriate action. But this looking can get tedious, and you might want to track stories in the news category or those by a particular author, rather than all of them. Moreover, it would be nice to receive notification of work-flow events via e-mail.
This functionality exists in Bricolage, and in true open-source fashion, it is customizable to an amazing degree. To create or modify alerts, click on the alert types menu item under the system menu in the lower right-hand side of the screen. This is one of the admin menus, meaning it's accessible only to users with administrative privileges. The resulting screen, like most other administrative screens in Bricolage, allows you to search for an alert by name or view all alerts that begin with a particular letter.
You can create a new alert type by clicking on the create new alert type link. This brings up a short HTML form that asks you to identify the Bricolage object on which you want to put an alert. So if you want to be alerted when something happens to stories, ask for alerts on stories. And if you want to be alerted when a new user is added to the system, ask for alerts on users. In short, almost any object in Bricolage can be placed under an alert.
As an example, let's create an alert to tell us when any story with “Linux” in the headline is moved from one desk to another. Once again, Bricolage makes it easy for us to monitor any object. This, however, is undoubtedly one of the more common types of alert that take place.
We now choose create new alert type from the admin menu, then create a new alert on Story objects. We then are presented with a list of actions that Bricolage can watch for us, ranging from category added to story to story published to element deleted from story. For this example, we choose Story moved to desk and name it Linux story moved.
Each alert type must have an owner; in this particular case, the owner is me, because I'm logged in as myself. The only user initially created by Bricolage, whose login is admin, is known as Bricolage Administrator. This admin user should be treated the same as the UNIX root user. It certainly can own alerts, but you are better off creating additional users (with the admin/user menu in the bottom left-hand corner), giving yourself administrative permissions and then logging in as yourself rather than as the administrator.
In any event, clicking on the next button at the bottom of this page brings you to the main alert type editing screen, which is used to create new alert types and modify existing ones. Each alert has four parts:
Properties: the name and owner of the alert type, which we entered on the previous page.
Rules: a description of when the alert should fire. Each rule consists of a variable (selected from a pull-down menu, thus avoiding the potential for misspellings), a comparison test and a text field into which you can enter the comparison value.
Content: the e-mail message sent to alert recipients. This can include a number of different variables, from the story's headline to its publication date.
Recipients: the users and groups who should receive the alert, if and when it fires. You can send an alert to all editors, to all authors or to George and Frank but not Deborah and Mary.
The rules are perhaps the most interesting part of the Bricolage alert system because of the relative ease with which nonprogrammers can create and edit them. However, there is the potential for danger with the =~ and !~ operators, which Perl programmers should recognize as indicators of regular expressions. This clearly is a double-edged sword, because regular expressions can be enormously powerful to the enlightened and extremely dangerous (and frustrating) to the ignorant.
So, we can create our alert by choosing Story title from the attribute list on the left side, =~ from the comparison operator list and entering Linux as the value in the text field, giving us:
Story title =~ Linux
We have to use =~ and not =, because we want to look for Linux in any part of the title rather than match the entire title. If we were interested in either Linux or Perl, we would search for:
Story title =~ Linux|Perl
Experienced Perl hackers might be pleasantly surprised to learn that =~ and !~ are case-insensitive here.
The subject and text of the alert can contain any text you wish, including interpolated Perl variables that Bricolage has defined for us. In a nice use of JavaScript, Bricolage lets you choose variables from a selection list, avoiding the possibility of typos and other errors. Also, this is a handy reference so you don't need to remember all of the variable names available when working with stories. In this manner, we can set the subject of the alert to be:
The story $title was just moved to $desk
The body of the alert message then contains a different message, but it also can contain variables. For example, you can set the alert to read:
You asked to be notified when Linux-related articles are moved to a new desk. Well, $trig_full_name just moved "$title" to the $desk desk. I hope you're happy now.
When an alert fires, its message is sent to all of the designated recipients in two different ways. An e-mail message is sent to each of the registered users, informing them, with the message we defined above, that the change has taken place. But Bricolage also keeps track of these items within its database, making it easy to keep track of alerts over the Web. For example, if an alert is fired from the Linux-related item we described above, we receive an indication by e-mail. But we also can see a summary of all the alerts we have received on the my alerts page, which you can get to by clicking on the my alerts button located at the top of each screen.
Alerts stay on this screen until they are acknowledged. The alert screen is not meant to be a long-term storage system; rather, it is a simple messaging agent that allows an editor to look at all of the relevant things that have happened to the site in the recent past.
You can acknowledge, and thus remove, an alert from the my alerts page by clicking in one or more check boxes and then selecting the acknowledge checked button at the bottom of the list. You also can acknowledge all of them at once, without having to use check boxes, by clicking on the acknowledge all button.
If I were the editor of a medium-sized Web site, I would spend a great deal of time defining alerts that would let me know when important events had occurred, such as when writers sent items to my desk.
Alerts are an excellent and practical way for Bricolage to bring relevant information to the appropriate user, rather than forcing users to go and seek out the information. But a side benefit of these alerts is they help new Bricolage administrators and programmers understand the different actions that can occur on different objects in the system. A simple example is the user object: we can create an alert that notifies us whenever users are created or deactivated, change their settings or change their password. This sort of alert is clearly uninteresting for editors but can be of supreme importance to system administrators.
A more complex example is the template object, which will be discussed next month. Templates define the ways in which stories are displayed, so it's important to keep track of them and any modifications made to them. Therefore, more items are associated with templates than with users—you can keep track of when a template is deployed, when it is edited and even when it is moved to its desk. Indeed, if you didn't previously understand that templates have their own desk, just like stories, the alert system would have made that clear to you.
I personally have learned quite a bit about Bricolage from poking through the system from different angles, including alert definitions. If you are new to Bricolage and haven't quite figured out how everything works, even after reading the documentation and expanding all of the menus (which is vital if you are to see where the different parts of a Bricolage site are defined and who has permission to set them), looking through the alert definitions makes things clearer. Moreover, if you are unsure of how a particular object is handled in the system, you always can create and register for an alert on that object, disabling it once you learn how it works.
As we saw last month, Bricolage is a large and complex system. Alerts make it possible for relevant information to pursue you, freeing you from having to hunt it down on a number of different screens. Although alerts are only a small part of the Bricolage system, they offer an intriguing view of its depth and breadth and of the options available with different objects.
