Wftax: Workflow on Taxonomy [#49537]

Attached is a heavily changed workflow module that uses vocabularies for workflows and terms for states. It still manages transitions and related actions itself, but it now interpolates with taxonomy modules much better.

I am including this as a full module, rather than patches, as it is such a huge change. This code is not v1.0 yet, but it is moving in the right direction.

Benefits

The primary goal of this module was to get workflow playing nicely with other taxonomy aware modules, specifically taxonomy access control. If you want to use taxonomy access control, you will have a devil of time getting workflow and noderperm_role to work with TAC.

While there are modules/patches to use multiple node access modules, I thought a better solution would be to bring workflow to the taxonomy system. It seems like a natural fit to me.

Here are some specific benefits:

Multiple workflows per node type: You are no longer limited to just one workflow per node type. You can now have a workflow for every conceivable purpose, all acting simultaneously. For example, you could have one workflow to edit grammar, another to check the logic of post, and another to make sure the styling is correct.
Easy listing of nodes in different states: You can just use the standard taxonomy/term/TID URI to get a listing of every node in a specific state. Very useful. There isn't any obvious way to find this path in the module right now, I'll add it soon.
Pull nodes out of workflows at any time: By making a workflow not-required, users have the option of pulling a node out of the workflow at any time. I don't know if this is a benefit or not, but hey! it's there.
Simpler schema: Only 2 tables now. Rock on.

Otherwise, this is pretty much the same as workflow (which you'll learn from looking at the code). There are some UI changes that may take a little getting used to. But it is basically the same.

Current code state

There are no known bugs in the code, except that the help text is in the wrong place. I moved some functions around and haven't had a chance to update and move the help text.

At the same time, I don't promise it will work 100% the same as the original workflow. Caveat emptor.

Also, I have certainly changed some of the functions and deleted others. The API is totally new. I'll look to get the code documentation up to spec after people review this code for functionality.

Finally, it would help to have some changes in taxonomy.module for UI purposes. Specifically, it would be nice to have taxonomy ignore module controlled vocabularies on node edit forms. See the debate at:

http://drupal.org/node/48599
http://drupal.org/node/38221

If you apply my patches at the above issues, the UI will look nicer.

One last note on code: for namespace purposes this module is in the wftax_* namespace. If you want to patch against workflow.module, I suggest you do a mass search/replace for wftax->workflow. Same for the schema.

Go at it. File bugs/problems. I would like to see this code merged back with workflow soon. Having 2 workflow modules is not in Drupal's interest. Though upgrading is going to be a pain for existing workflow users....

Comment	File	Size	Author
	wftax.tar.gz	30 KB	mfredrickson

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

jvandyk CreditAttribution: jvandyk commented 16 February 2006 at 14:23

When we designed workflow, one of our first thought was "Let's use taxonomy for the workflow states." But we rejected this in favor of private workflow tables because

- taxonomy vocabularies have no security without third-party hacks
- the aim is to get workflow into core and replace the hardcoded pseudo-workflow system Drupal has now.
- the benefit (that taxonomy gives for free) are views, which should be provided by the views.module (and perhaps some vanilla views provided by workflow itself). Views gives us a much more customizable way of viewing workflow state views, including security, while taxonomy gives no security. Many times there will be cases where we do not want some view states exposed (think of submissions to a granting agency, for example, or submissions for a scholarship review).

The other benefit stated for using taxonomy is that you could pull a node out of a workflow. You didn't give a use case, and I can't think of one. You can always create a "none" state to emulate that.

I don't think the db schema matters. Workflow tables are small and fast.

To get there from here, we need to add views support to workflow, which is easy; and we need to add support for multiple workflows, which is not hard either (we need to use an array in the $node object). For other action items, see the outcomes from the Vacouver workflow session.

Comment #2

mfredrickson CreditAttribution: mfredrickson commented 16 February 2006 at 16:14

As an overview to my comments: taxonomy has changed slightly, and people are clamoring for more changes that allow modules to manage vocabularies through a standardized API. Admittedly those features are not in place yet, but with more support for and work done on those features, I still think taxonomy is the way to go.

Now to address some specific points:

taxonomy vocabularies have no security without third-party hacks

I see this as a two part problem: a) there is no way to make a vocabulary "private" and not displayed in the "categories" field set in the node_edit form. b) there is no way to prevent admins from manually editing system controlled vocabularies.

There is emerging work on this. Check the two links I included in the original post. I'm going to put more there. It boils down to the fact that modules can now register that they control a vocab. Taxonomy doesn't do anything with this information, but the information is there. Hopefully this will address the first point and allow modules to "turn off" display of their vocabs in the "categories" drop down list.

As to b), I don't think we should worry too much about this. I submitted a small patch to make the information (that is, the contents of the module field) available to admins. If they want to mess with the vocabs. Also, taxonomy does call hooks when it deletes terms and vocabs. We could use these to block the deletion (perhaps) or to gracefully handle it.

the aim is to get workflow into core and replace the hardcoded pseudo-workflow system Drupal has now.

Good. This too is my goal. Taxonomy is in core though, so I can't see a reason why this prevents us from using it. In fact, I see that as a benefit to taxonomy. Core systems should rely on each other, not recreate the wheel. The data structure for a taxonomy vocabulary is very robust: it can be required or not, it can apply to each node type or not, it can include help fields and description fields.

I would like to see an API enforce the single-select, multi-select, etc properties. Right now, there is no such API. This gets back to my theme: Fix taxonomy while upgrading modules to use the new features/API.

the benefit (that taxonomy gives for free) are views, which should be provided by the views.module ... including security, while taxonomy gives no security.

Why can't we use taxonomy and let views use the existing taxonomy features? You don't have to use taxonomy/term/TID, you can use the views module instead. With states as terms, admins have the choice.

As to the larger issue of security, I think (again) the "tates as terms" model has big advantages. With "states as terms" I can either use taxonomy access control or nodeperm_role (or node_privacy_by_role) + actions to control access. In the states as a separate table, you can only use nodeperm_by role + actions.

To me, using taxonomy access control is a simpler solution, but others might want nodeperm. By using terms instead of custom states, admins have the freedom to choose either.

Conclusion
This post is getting long so I'll wrap it up by returning to my basic point: taxonomy isn't perfect but it is close. If we can hammer out an API for modules to use then we can provide a much more robust workflow. Even without the API, we can still provide a more robust workflow by piggybacking off of the taxonomy module.

I will provide a new tar.gz soon, with some small UI and bug fixes.

I would be very interested to know the results of the workflow group. I'll go scour the OSCMS summary wiki to see what I can find. If anyone has specific write ups, would you post them on this issue?

Thanks.

Comment #3

merlinofchaos CreditAttribution: merlinofchaos commented 16 February 2006 at 16:36

Having written hacks to workflow that use taxonomy for access control, I didn't like the result. I don't really recommend this. Taxonomy should be used for what it's good at, not what it's been hacked to do, IMO, and the real issue is that node access needs to be fixed, not that taxonomy needs to be overloaded even more to work around node access not being powerful enough.

Comment #4

mfredrickson CreditAttribution: mfredrickson commented 16 February 2006 at 21:54

I guess I fail to see why this is a hack. Taxonomy is designed to mark nodes in some way. A state in a work flow is a marker on a node. Taxonomy has a couple of bugs, but I think they can be fixed.

I've identified three short comings that I think are fairly easy to address. They are here:

http://drupal.org/node/38221#comment-73950

The most important for node access purposes is the lack of notice when node taxonomy terms change.

I agree that node access itself is problematic, but that doesn't excuse us from writing modules that don't work together. If taxonomy access is failing right now, it doesn't mean the concept is strong.

Consider this use case:

I set up a workflow vocabulary with three states:
draft <--> please review <--> published

I give my authors full access to the draft term and readonly access to the please review state. I give my editors full access to the review and draft terms. I give anonymous users view access to the published term only. I set up the transitions appropriately.

I set all nodes to be "published" in the hard coded work flow (so that my authors and editors can see them) and I'm set.

Boom. Instant, flexible workflow replacement for Drupal's hardcoded system. If you don't like this sytem, you don't have to use it and can rely on the traditional model.

We are very close to being able to do this, it just requires a few changes in taxonomy.module and then updating taxonomy_access and wftax to use them.

Comment #5

sangamreddi CreditAttribution: sangamreddi commented 2 March 2006 at 21:36

I like the concept and will give a try on Wftax: Workflow on Taxonomy module. I see the workflow is pretty straight forward and simple with this module.

Comment #6

mfredrickson CreditAttribution: mfredrickson commented 2 March 2006 at 21:59

I'm glad you may find it useful. Be careful, though. This code is very rough and Drupal's taxonomy system could benefit from some upgrades. I will revisit this module more after I create some patches for taxonomy. Hopefully they will integrated into core for Drupal 4.8.