I grabbed the LdapOverlay solution for using an LDAP server to authenticate against Request Tracker today in my continuing efforts to use LDAP for single sign-on for all Kineticode resources. It worked great, but I wanted a couple more things out of it, namely TLS communications with the LDAP server (so that all communications are encrypted), and authentication only for members of a certain LDAP group.

So I refactored LdapOverlay and added these features. You can download it from here. Just set the $LdapTLS variable in your RT_SiteConfig module to a true value to use TLS (but be sure that you also have Net::SSLeay installed!). If you want to allow only members of a certain LDAP group to authenticate to RT, set the DN of the group in the $LdapGroup variable, and set the name of the member attribute (usually “uniqueMember”) in the $LdapGroupAttribute variable.

Enjoy!

Looking for the comments? Try the old layout.

I expect that this will be my last release of SVN::Notify for a while. I’ve already spent more time on it than I had anticipated. But anyway, this is a pretty solid release. It doesn’t change the API or anything, but I feel that the jump from 2.30 to 2.40 is justified because of the sheer number of changes. From now on, I expect that it will mostly be maintenance, like 2.41, which fixes a minor formatting bug. Grab it now from CPAN.

First, I’ve added a new, complex example of the SVN::Notify::HTML::ColorDiff output that I will keep up-to-date with all future changes. This will allow people to get a better idea of what it’s capable of than my previous contrived examples allowed.

The biggest change is that I’ve moved the Request Tracker, Bugzilla, and JIRA support from SVN::Notify::HTML to SVN::Notify. I realized, after the release of 2.30, that it might be cool to add links to the text-only email message generated by SVN::Notify, too. So I’ve done that, including for ViewCVS links. Unlike in SVN::Notify::HTML, the links won’t be inline in the message (that doesn’t work too well in plain text, IMO), but will come in their own sections after the message. So you’ll get something like this (extreme example):

Log Message:
-----------
Let's try a few links to other applications. First, we have
A Bugzilla Bug # 709. Then we have a JIRA key, TST-1608. And
finally, we have an RT link to Ticket # 4321.

Hey, we could add one to ViewCVS for a Subversion Revision
#606, too!

ViewCVS Links:
-------------
    http://viewsvn.bricolage.cc/?rev=606&view=rev

Bugzilla Links:
--------------
    http://bugzilla.mozilla.org/show_bug.cgi?id=709

RT Links:
--------
    http://rt.cpan.org/NoAuth/Bugs.html?id=4321

JIRA Links:
----------
    http://jira.atlassian.com/secure/ViewIssue.jspa?key=TST-1608

The nice thing is that, for many mail clients, these will be turned into clickable links. You’ll also notice that the text that creates the ViewCVS link is split over two lines. This is new in this release, and works for SVN::Notify::HTML, too. I made a few other tweaks to the regular expressions, as well. Here’s a complete list of changes:

• Fixed accessor generation so that accessors created for the attributes passed to register_attributes() but a subclass are created in the subclass’ package instead of in SVN::Notify.
• Changed parsing for JIRA keys to use any set of capital letters followed by a dash and then a number, rather than the literal string “JIRA-” followed by a number. Reported by Garrett Rooney.
• Modified the regular expression patterns for the RT, Bugzilla, RT, and ViewCVS links to properly match on word boundaries, so that strings like “humbug 12” don’t match.
• Modified the ViewCVS link regular expression pattern so that it matches strings like “rev 12” as well as “revision 12”.
• Modified the RT link regular expression pattern so that it matches strings like “RT-Ticket: 23” as well as “Ticket 1234”. Suggested by Jesse Vincent.
• Added complicated example to try to show off all of the major features. I will keep this up-to-date going forward in order to post sample output on the Web.
• Fixed the parsing of log messages so that empty lines are no longer eliminated.
• HTML::ColorDiff now properly handles the listing of binary files in the diff, marking them with a new class, “binary”, and using the same CSS as is used for the “propset” class.
• In HTML::ColorDiff, Fixed CSS for the “delfile” class to properly wrap it in a border like the other files in the diff.
• Added labels to the HTML::ColorDiff diff file sections to indicate the type of change (“Modified”, “Added”, “Deleted”, or “Property changes”).
• Moved the rt_url, bugzilla_url, and jira_url parameters from SVN::Notify::HTML to SVN::Notify, where they are used to add URLs to the text version of log messages.

Enjoy!

Looking for the comments? Try the old layout.

I released a new version of SVN::Notify last night, 2.30. This new version has a few things going for it.

First, and most obviously from the point of view of users of the HTML subclass, I’ve added new options for specifying Request Tracker, Bugzilla, and JIRA URLs. The --rt-url, --bugzilla-url, and --jira-url options have an effect much like the parallel feature in CVSspam: pass in a string with the spot for the ID represented by %s, such as http://rt.cpan.org/NoAuth/Bugs.html?id=%s for RT or http://bugzilla.mozilla.org/show_bug.cgi?id=%s for Bugzilla. SVN::Notify::HTML will then look for the appropriate strings (such as “Ticket # 1234” for RT or “Bug # 4321” for Bugzilla) and turn them into URLs.

This functionality has been extended to the old --viewcvs-url option, to. For the sake of consistency, it now also requires a URL of the same form (although if SVN::Notify doesn’t see %s in the string, it will append a default and emit a warning), and will be used to create links for strings like “Revision 654” in the log message.

SVN::Notify::HTML has an additional new option, --linkize, that will force any email addresses or URLs it finds in the log message to be turned into links. Again, this works like it does for CVSspam; I’m grateful to Jeffrey Friedl’s Mastering Regular Expressions, Second Edition for the excellent regular expressions for matching URLs and email addresses.

All of this was made possible by moving the processing of options from svnnotify to SVN::Notify->get_options and adding a new class method, SVN::Notify->register_attributes. This second method allows Bricolage subclasses to easily add new attributes; register_attributes() will create accessor methods and add command-line option processing for each new attribute required by a subclass. Then, when you execute svnnotify --handler HTML, SVN::Notify->get_options processes the default options, loads the SVN::Notify::Handler subclass, and then processes any options specified by the subclass. The short story is that all of this is the detail-oriented way of saying that it is easier to subclass SVN::Notify and be able to automatically load the necessary options and attributes via the same executable, svnnotify.

This change was motivated not only by my desire to add the new features to SVN::Notify::HTML, but also by Autrijus’ new modules, SVN::Notify::Snapshot and SVN::Notify::Config. Thanks Autrijus!

I’ll try to get a nice example of all this functionality up in the next few days; if anyone else creates one first, send it to me! But in the meantime, enjoy!

Looking for the comments? Try the old layout.