At the Forge - Bricolage Alerts

Keep track of what's happening on your Web site with alerts for key events.

Alert Rules

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.

Receiving Alerts

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.

Learning from Alerts

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.

Trending Topics

Upcoming Webinar

Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report

August 27, 2015
12:00 PM CDT

DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.