David Raynes

In the last week, I have been surprised at the amount of interest in Workflow in the educational and not-for-profit realms. So, I would like to announce pricing for licenses for educational and not-for-profit organizations: $150 for the base license covering the first server, and $50 for each additional server beyond that. These licenses come with the same level of support as the commercial license.

Until I can work out an automated way to handle payments, please contact me directly with your requirements and I will send out an invoice.

Workflow 1.0.2 is out. This release fixes a bug in the entry transfer notification that I introduced with the callback tweeks I released with 1.0.1.

Hop on over to the Workflow page for the download links.

Workflow commercial licenses are now available, along with a minor update in the plugin itself. Please visit the Workflow page for more information and download links.

A commercial Workflow license costs $250 and applies for all 1.x versions of the plugin. Here is what the license will get you:

• Official support channel unavailable to personal users, with a goal of 48 hour turn around time on support requests
• Early access to new beta releases
• Optional promotion on the Workflow page as a Workflow user

As a way to both promote the extensibility of Workflow and just to see what the Movable Type development community can come up with, I am going to run a plugin contest for Workflow plugins.

The details are still being ironed out, but the folks at Six Apart have already generously promised to provide some of their new t-shirts as prizes. I will probably toss in some iTunes gift certificates as well.

More details as I work things out.

My favorite part of developing Workflow was implementing a plugin system for it. Now it is time for me to tell you folks about all of the ways you can extend and customize Workflow for your specific situations.

Workflow Callbacks

All Workflow callbacks can be added to through the add_callback method of the MT module:

MT->add_callback ('Workflow::CALLBACK_NAME', $priority, $plugin, \&subroutine_ref);

Creating a Workflow plugin

To add your own custom code to Workflow, simply create place your code in a .pl file in the /plugins/Workflow/plugins/ directory. What code are you going to put in that file? I will cover that next.

Adding a permissions setup option

The list of permissions setup options you can select from when first setting up a blog for Workflow can be modified. The two default options are defined in /plugins/Workflow/workflow.pl. To add your own, use the add_setup_option method of the Workflow module. That method takes two arguments: the option name and a hash reference containing all of the details for that option.

require Workflow;
Workflow->add_setup_option ('Option Name', {
    desc => 'Option description',
    can_grant => sub { 1; },
    can_publish => sub { 1; }
});

The values for the can_grant and can_publish keys are subroutine references that are passed parameters in the fashion of normal Movable Type callbacks with the following parameters: the Workflow::App object and the MT::Permission object for the current blog and author being setup. The subroutine should return a true value if the author should be allowed to grant publish permissions or publish respectively.

For example, the Open Publishing setup option uses the following subroutines to give all those authors who can edit all posts permission to grant publish permissions and all those authors who can post publish permission.

can_grant => sub { $_[2]->can_edit_all_posts },
can_publish => sub { $_[2]->can_post }

And beyond that, every setup option can be extended beyond its initial setup. Simply add a callback to either Workflow::OPTION_NAME::SetupGrant or Workflow::OPTION_NAME::SetupPublish where OPTION_NAME is the name of the setup option (e.g. "Open Publishing"). And there are global callbacks that are called no matter what setup option was selected: Workflow::SetupGrant and Workflow::SetupPublish.

Supplementing the entry transfer process

To whom can an entry be transferred?

A Workflow plugin can restrict the list of authors to whom an entry can be transferred. The Workflow::CanTransfer callback, if the subroutine returns a false value, can prevent an author from appearing on the list of available authors to whom an entry can be transferred. The callback subroutines are passed the following parameters: the Workflow::App object, the MT::Entry object representing the entry that will be transferred, the MT::Author object representing the author to whom the entry would be transferred, and the MT::Author object representing the author who is doing the transferring (not necessarily the author of the entry).

A Workflow plugin could define a list of authors that are responsible for particular categories and then only allow those authors to be transferred entries for those categories.

What to do before an entry is transferred?

The Workflow::PreTransfer callback takes the same parameters as the Workflow::CanTransfer callback and is only run right before an entry is transferred after it is verified that it can be transferred to the specified author.

What to do after an entry is transferred?

The Workflow::PostTransfer callback is run after the entry is transferred. It takes the following parameters: the Workflow::App object, the MT::Entry object representing the entry transferred, the MT::Author object representing the author from whom the entry was transferred, and the MT::Author object representing the author who did the transferring. For example, this is the callback that the plugin uses to send the entry transfer notification.

A Workflow plugin could implement an entirely new form of notification, for example sending an instant message with the Net::AIM module.

Supplementing publishing permissions

The Workflow::CanPublish callback is called when an author attempts to publish an entry. If the callback returns a false value, the entry will be switched to draft. It takes the following parameters: the current MT app (either Workflow::App or MT::App::CMS), the MT::Author object representing the author attempting to publish, and the MT::Entry object representing the entry attempting to be published.

Here it is, folks. Workflow 1.0 is ready to go. The version I am releasing today is solely for personal use, and may be used as an evaluation version for commercial usage (but please limit the evaluation to 30 days or less). I am still finalizing the commercial license for this plugin, but I wanted to get a version of it out there while I finish up what is needed.

So, here is how to get your very own copy of Workflow. Download one of the following archives and unpack it in the main directory of your Movable Type installation. It will install files into the plugins/Workflow/ directory, and you will need to make sure that workflow.cgi has the correct permissions to execute as a CGI script (on Unix hosts, that would be 755).

• workflow-1.0.zip
• workflow-1.0.tar.gz

To use the entry transfer feature of Workflow, simply click the "Transfer ownership of this entry" link at the bottom of the entry edit page.

To use the publish control feature of Workflow, click the "Edit Publish Permissions" link at the bottom of the main blog page and follow the instructions on the resulting page.

But that is not all that Workflow offers you. It has its own plugin system that will allow developers to add additional setup options for publish permissions, as well as more conditions under which an entry may or may not be published by the current author. And that is not even the half of it. I will go into more detail on Workflow plugins in another entry.

This plugin requires Movable Type 3.1 or greater. There is an official Workflow support forum on my site (honestly, mainly because I do not have the time to troll through the MT support forums for Workflow problems). I will be keeping an eye on that as best I can. If you discover a bug in Workflow or there is a feature you would like to see, please create a ticket.

Of all the plugins I have written so far, I am most proud of this one. Enjoy!

After finishing up the last few bits of code for Workflow last night, I am freezing the feature list and only committing bug fixes to the trunk now. I released the first real release candidate to the testers last night, and in a couple weeks time, there should be a nicely polished official release of Workflow 1.0 for Movable Type 3.1 or later.

The commercial version will be made available as soon as the I stamp the "official release" label on the code. A version for personal use will be made available when the Dropcash campaign is completed.

I am very excited to get this out the door. I think this is going to be big.

I just finished implementing the latest feature for Workflow: transfer notification emails. So when an author transfers an entry from its current author to another one, the new author will be notified of their new responsibility. This is the last planned feature for Workflow 1.0. Now it is time to pass this along to the testers and clean it up for release.

And while the testers are doing their thing, I can finally put some time into the "Plugin Store" that I have been tinkering with. Anybody feel like giving me a hand with that (especially on the design side of things)? I suppose I could toss in free commercial licenses for Workflow 1.0 and MultiBlog 2.0 (when that comes out) as an incentive.

One thing has made itself glaringly obvious over the last few weeks while I have been periodically working on my Workflow plugin: writing plugins of significant functionality for MT 3.1x is disturbingly easy.

While there are still some features I would like to see, namely more application level callbacks for me to hook my code into, getting Workflow to the planned level of functionality was actually so easy that I ended up adding additional features that were not part of the original feature list. I was expecting to spend most of my time with the plugin working out some fancy perl tricks to accomplish what I wanted (if you have looked at some of the perl acrobatics Jay employed in the "integration" of MT-Blacklist with older versions of MT, you will understand what I am talking about). Instead, the callback methods I wrote worked perfectly the first time, which meant that I could spend extra time on the configuration interface (and I think that extra time is reflected quite well, if I do say so myself).

I remember my first real plugin: MTSearches. I am nearly dumbfounded every time I think of what us plugin developers could write back then and what is possible now. It is a couple orders of magnitude beyond what it used to be. Here are some revealing numbers I have pulled together:

• MTSearches plugin
  • 130 lines of code
  • 6 template tags, using data culled from the activity log

• Workflow plugin portion (not including the configuration app)
  • 117 lines of code
  • 5 template tags, populated by custom information stored by the config. app
  • 2 links added to the MT web interface (for blogs and for entries)
  • 1 application level callback (preventing users from setting an entry to publish without permission)

And I think we are only scratching the surface of what a plugin can do. I look forward to seeing what the future holds.

I have now completed what I consider to be the first full featured version of the Workflow plugin. That is to say, it has the two main features I had planned for the 1.0 release version:

• The ability for an author to pass ownership of an entry to any other author with appropriate permissions.
• Finer control over who may publish an entry (i.e. just because you can post, does not mean you can publish)

I am looking for a few good testers to put this plugin through its paces before I make the final public release. If you are interested, leave a comment or send me an email, and I will get back to you with the conditions for being one of the testers.

In some preliminary testing, what I was expecting to be the major hurdle for the second part of the Workflow plugin, controlling whether or not an entry could be published or forced back into a draft, turned out to be a little less the a minor speed bump. All I need to do now is wrap some configuration and UI goodness around it, and there will soon be a Workflow 1.0.

This is just a quick update for the Workflow plugin. It now adds a log entry when an entry is transferred to a new author.

To install it, download one of the following files and follow the instructions detailed for the previous version.

Download one of the following files:

• workflow-0.6.tar.gz
• workflow-0.6.zip

If you find this plugin useful, or are eagerly anticipating the planned features of a future version, please considering a donation to the dropcash campaign for Workflow (or, heck, if you wanted to, there is always my Amazon wish list).

Workflow is a plugin for Movable Type 3.1 which lets an author pass ownership of an entry to any other author in Movable Type with appropriate permissions.

This plugin is the beginning of a more complex workflow system for Movable Type. Initially, all it does is support the transfer of entry ownership from one author to another. If you can edit an entry, you can hand it off to somebody else.

Download one of the following files:

• workflow-0.5.tar.gz
• workflow-0.5.zip

To install, create a directory named Workflow in your plugins/ directory and unpack the contents of the archive in there. Be sure to give mt-workflow.cgi permission to execute (e.g. chmod 755).

To transfer an entry, simply load up the entry in question in the interface, scroll down to the bottom of the page and click the "Transfer ownership of this entry" link.

This plugin requires MT 3.1. I should also note that when an entry is transferred via this plugin, in addition to triggering a rebuild, this plugin will also call any callbacks associated with AppPostEntrySave.

Next in line for this plugin is the hard part: separating those users than can merely post to the blog (i.e. 'Draft' entries only) from those that can actually publish an entry. That will be quite a lot more work than this portion of the plugin, but I wanted to get what I have written so far out there first. If you find this useful and/or would like to have the more granular post permissions, please consider donating some money to the dropcash campaign I established for this plugin.

One of my personal side projects has developed a need for a more robust workflow system with Movable Type. This would include, but not be limited to:

• transferal of ownership of an individual entry from one author to another
• restricting the ability of an author to post non-Draft entries.

Those, at least, are the two particular requirements I am working from initially. As needs arise in my project, or requests are made for general functionality for the plugin, I will incorporate them as best I can.

I have created a dropcash campaign for the workflow plugin. Upon completion of that campaign, I will release a version of what I am developing to the public.