A while back catch created a feature request for the Project issue tracking module to allow free tagging on issues (see http://drupal.org/node/187480). The use case he indicated was to be able to attach certain labels to issues, for example benchmark, needs re-roll, needs doxygen, etc. Other use cases would include tagging issues that need testing in certain ways (eg. MySQL, PGSQL, Javascript, IE, etc.) and tagging issues that are good for certain audiences (eg. newbie, GHOP, DROP, etc.).
Webchick originally wrote a skeleton module called Comment alter taxonomy with the intention of allowing comments to nodes (including project issues) to add/remove/change the taxonomy term(s) assigned to nodes. I took her code from there and added the data storage capabilities to make it actually work. I've created the project and committed my working but not yet finished code at http://drupal.org/project/comment_alter_taxonomy.
I'd love to get reviews of this code as well as have people make suggestions of potential use cases for this module outside of project issues. Right now the module will work with nodes of all types but there is no capability to display changes made in individual comments outside of project issue nodes. Off the top of my head I can't think of how this would be necessary in other node types, but I'm sure some of you would have good suggestions.
I hope that once this module is complete and well tested that it can be deployed on d.o for use with project issues. I'm not sure what kind of implementation we'll eventually have (ie. free tagging vs. administrator created terms), but I think the functionality provided by this module could really improve the workflow in the d.o issue queue.
I've attached a screenshot of this module in action in a simple use case.
Here are the specific things that I'd like suggestions on:
- Non project-issue use cases. How would you want changes to terms in individual comments displayed?
- At the moment, this module disables editing taxonomy terms that can be altered by comments when editing (but not creating) a node. Likewise, editing of terms in a comment (but not when adding a comment) is disabled. These decisions were made to increase the integrity of the history of terms attached to the node. Will this be a problem in certain use cases?
- When a comment that alters taxonomy terms is deleted/unpublished, the term changes made in said comment are not reverted. This behavior is different than how the project issue module treats changes in metadata (such as status) but is the same as how the Google Code issue tracker treats deleted comments. I'm not convinced that the current behavior is the most desired, but it turned out to be easier to code :)
For the sake of completeness, even after this module is finished there are still a few more steps that are necessary to make this useful:
- To display the term changes in an issue, #219734: Allow theming of changes in project issue table and email needs to be finished.
- To allow searching for specific terms within issue queues for a given project, I think we'll need to add on something to the current project issue tracking module, because I don't think it's possible to do this yet in its current state. The refactoring of project issue to use views (#76725) should help out with this.
| Attachment | Size |
|---|---|
| cat_example1.png | 56.81 KB |
Comments
non-project-issue use
Hi Adam,
This looks interesting.
From what I understand so far, I can see one non-project-issue use for this module. It's potentially a powerful feature for intranets/knowledge-bases (like social tagging). It facilitates the way an organization discovers what its members are thinking about and what type of information they need at a given period.
Let's say the content editors of the corporate intranet defines a specific Taxonomy. The org starts using this Taxonomy but soon, members realize that the content may also be used in other ways. As they post comments, the module you are creating (if I got it right), will realize changes in the way the content is being used (eg, unusual uses, unexpected uses, etc). This is an important indicator for a knowledge-based organization.
Is there a way to test your work online? Kindly send me a link so I can better understand and help test. Thanks!
"Work smarter, not harder."
The Power of Drupal Categories
A Podcast for Mac Switchers
User Experience Design
A Podcast for Mac Switchers
As they post comments, the
I'm not quite sure what you mean here, but if an administrator has allowed terms of a given vocabulary to be altered in comments, and that vocabulary applies to the given node, and the user making the comment is in a role that is allowed to alter the terms of the vocabulary, then the user making the comment can change the terms associated with the node from the comment. Kind of confusing, I guess.
The thing is that right now, unless the node is a project issue, the comment itself will not indicate that the terms associated with the node were changed in that comment. The only change is that the node itself will display the new terms.
I just realized that in the example screenshot I attached above, there's a little bug. PGSQL should not be displayed in the node body or in the top metadata table, since that term was removed in comment #2. At the moment, nodes that are not project issue nodes would not have the metadata tables anywhere. I'm willing to implement something similar in non project-issue nodes, but I'm not sure if that's necessary and if so what the best way to do this is.
Nope, not yet. I still want to finish a few loose ends up with the module and then go back through and make sure I don't have any security holes. Once I do that I may create a demo site. If so I'll post the address here. This is unlikely to happen until after DrupalCon, however.
Use cases
A couple more use cases:
Support forums. New posts tagged with "Open", someone giving a reply can change it to "Partly answered" or "Answered".
A glossary/definition list with option for discussions for each entry. Possibility to add and remove an "under discussion" tag. (Example: Drupal glossaries used by translation teams. Some terms will be difficult to translate or have several possible translations. Would be useful to pull out a list of terms with open discussions.)
For both those use cases, the change in terms can/should be shown in the same way as in your issue queue example. Off hand, I can't think of a use case where I wouldn't want to show the changes.
As long as the current terms are shown at the top of the node, it shouldn't be a problem for those use cases.
One thing that's nice to have, but probably not essential: The ability to theme changes differently depending on what change it is. It might be desirable to highlight changes to a specific term, or changes within a specific vocabulary. In other words, add to the much lamented CSS soup of Drupal :-) by having different CSS classes for each vocab and term. I've no idea how hard or difficult to code that would be.
--
Hilde Austlid, Drupalchick