Redmine

It should be possible to enter a number of tags / super tags i.e. tags that are made up by nesting tags e.g. person:living:(sex:male):(dob:(format:YYYYMMDD):19761103):(age:33):(photo:(filetype:((mime:image/jpeg):(extension:.jpeg))):(file:$FILE²)

'note: in the super tags I've put the file name as $FILE² to show that other data in the object (in this case it could be the second file uploaded for an issue) should be referanceable in the super tag, this would then enable the information in the super tag to provide some additional meta data and relation between data in the object, I suppose if could also be done dynamically or expanded, though an expanded version should always be kept when the object is saved to allow it to be searched and indexed without having to re-parse and lookup and substitute the referenced data'

against things like project / files / issues etc.. that can then be used for all kinds of things like searching and categorization and use to store meta-data against things.

It's a very useful feature to have because it allows the storage of very rich (if using the super tags idea) but concise meta-data relating to the object that you quite often don't want to actually put in the data for the object (or there is no ability to put in the data for the object).

It makes things like searching much more powerful and enables a reasonable level of prompting / auto compleation / filtering for things like search and for entering the tags themselfs.

It also allows for rich categorization and generating dynamic (which could also be made persistant) relationships between objects.

A tags feature (with code behind it to work with the tags and enable the features that can be driven by them or extending existing features) provides a way for user defined data to be related to a specific object or sub-object / field (like a file is a sub object or an issue for instance) without having to set up lots of individual fields for the user to input data (which I believe would be the only way to do it if there wasn't relating code to work with tags). The super tags idea makes the feature incredibly powerful and dynamic.

Stats can also be kept about the usage of tags both in terms of how many time a particular tag has been used in a tag set and how many times a particular tag has been used in a feature that uses tags e.g. filtering / searching.

To give you an idea of the king of things super tags allow I'll say that I'm currently writing a specification and some parsers for 'super tags' and will attach it to this ticket unless you think the idea of having tags is bad for some reason. I'm currently planning an implementation of super tags for deb packages so that I can then make really cool things happen on systems using deb packages (e.g. when you download something who's mime type isn't supported on the system the packages list can be searched for to find something that supports that mime type allowing the user to install it, but they won't just be prompted with a list of things they can install they can be given much more user friendly options like view in embedded view, edit in gimp image editor [installed] etc... because super tags not only allow me to specify for instance what mime and extension are supported by a particular application / plugin or what ever but also what kind of actions can be performed and even how those actions can be performed.)

Anyhow, it makes sense if other people want to implement something like 'super tags' that there's a common specification that can be used so that users learn how to do it in one thing that uses that kind of feature and they can then use it when in another app that supports that kind of feature and the implementation is already familiar to them.

I've categories this as 'custom fields' because it's a request for a new type of field but one that can be related to many different types of objects or even to other fields / custom fields (e.g attachments)

'apologies for the possibly incorrect words picked from the spell checker and the poor grammar, I write computer software not literature . I may not be able to write up things very well but my bug reports and feature requests are built on 25 years of software design and development expertise , working with users etc... so hopefully the ideas and issues are pretty good even if the write-up isn't that readable. So if anything is ambiguous or doesn't seem to make sense / or difficult to read the way I've written it please ask me to explain or try to clarify as I'll be more than happy to do so'