I think there is to gain in using "State" and "priority" as terms in a possible "jobtracker" vocabulary. it would make it easier to manage tickets by category and use other modules enhancements, like one could use content_access permissions based on taxonomy.

I would even dare to suggest this for the clients, if I knew it was easy afterwards to get an email address associated with it.

Anyway, just a suggestion.

Thanks for the good work

Comments

jeremy’s picture

jeremy commented
Status: Active » Postponed

Interesting idea, but not something I need right now. Postponing until someone submits a well written patch or funds the development effort.

jeremy’s picture

jeremy commented
Title: make use of taxonomy » use taxonomy for ticket states and priorities

Updating title to properly reflect the feature request.

Unfortunately there's added complexity to this because priorities and states are more than just names and weights - there are other fields involved (whether or not a given item is the default, and for states which phase and whether it's a closed state. If converted to taxonomy, we'd still have to maintain information about each term in another database table, and doing so would tie us intimately to taxonomy preventing the use of jobtrack with non-core taxonomy-type replacements (like Category).

jeremy’s picture

jeremy commented
Status: Postponed » Closed (won't fix)

Closing feature, as the caveat I mentioned makes it less attractive to me.

lotyrin’s picture

lotyrin commented

sub

taxonomies are entities in 7, a port might be able to use taxo, since the taxo term entities could have fields for the extra support-related information.