The same thread also pitched another supporting idea that would go hand-in-hand with a new tagging interface.

[[quote]]
an interesting concept for the catagory vs. tag system would be "smart folders". We use that in a Wiki, where a smart folder collects all items with a set of common tags/keywords. With this structure does not matter, as long as the content is correctly tagged, which I think makes the system very flexible.
[[/quote]]

Nothing personal on this one Anders. I didn't realize you actually JIRA'd this before I got a chance to read your forum post. I'm moving all these ideas into the issue I created, CHD-920, simply because I've already linked that one to a bunch of other ideas. Ironically all these ideas partially spawned from talking with the developers about your complaint specifically :)

So basically it would be harder for me to restructure this issue as opposed to moving your ideas over.

Copied Anders ideas directly into the description.

Almost identical idea that spawned from two different people in different threads that were not collaborating ;).

CHD-917 is more about merging tickets with KB articles without necessarily a tagging system in place.

CHD-920 is the 3.x way of using tags to force a link between tickets and the KB.

I used to despise tags, so I know where all the tag-haters are coming from, but I recently gained a thorough appreciation for them. I think there's room for both hierarchical categorization and tags/keywords in the KB, for maximum flexibility in searching. People who still hate tags can choose not to use them, but everyone who has discovered their utility would greatly benefit from their presence in KB articles.

I also support reintroducing tagging. Categories are good for browsing, but there's nothing like a tag to get to the meat of the issue. If the customer is asking about returns, tag it returns and it doesn't matter where the kb article is filed categorically (somewhere up on the FAQ tree..) -- it comes right back. Also let us tag topics that emerged from several directions (quality, kudos, etc.) and go back later to pull up all the relevant tickets on the topic.

Tags are not evil.

I am a big fan of information retrieval using tags, and would like to see this feature included as an option in a future release of help desk.

For example, we'd like to be able to flag all tickets containing feature requests, so they can compiled and tabulated once a month. This would be easy to do with tags. Not so easy with the current setup.

I am also currently against tags in Cerb4; especially when Cerb3 is the example. We can continue to explore ways to link tickets against KB/templates.

Tags were an interesting concept if they had related 'terms' that could match incoming content, and were merely a way to group those terms. There's nothing stopping functionality like that in plugins w/o making it mandatory in core.

Tags actually wouldn't be too difficult by this point, since we have a reusable autocomplete component (used by choosers all over the place), and a connection/linking service in the platform that could track the links between tag objects and and any other record. We also have a lot of other benefits baked into the platform -- we'd automatically have worklists for each tag to see the related content (KB articles, tickets, tasks, etc). It would also be simple to use connections to find arbitrary records that shared a combination of tags.