Flyspray - The bug killer!

After looking and working a bit on the tags feature I come to the point where I think it is better to change the db tables now. Instead of trying to make it a bit useable with the current (non)implementation and reworking it later.

The current situation is that the tags at the moment are not useful. They aren't show in task list, not filterable, not searchable, and not stylable (colors!, icons! )
And losing the few tags who are exists in FS1.0dev installs do not hurt, IMHO.

Instead I prefer simply changing table tags from current

<table name="tags">
 <field name="task_id" type="I" size="5"></field>
 <field name="tag" type="C" size="100"></field>
</table>

to

<table name="tags">
 <field name="tag_id" type="I" size="5">
  <KEY/>
  <AUTOINCREMENT/>
 </field>
 <field name="project_id" type="I" size="5">
  <NOTNULL/>
  <DEFAULT value="0"/>
 </field>
 <field name="tag_name" type="C" size="40">
  <NOTNULL/>
 </field>
 <field name="class" type="C" size="100"></field>
 <index name="tag_name">
  <UNIQUE/>
  <col>project_id</col>
  <col>tag_name</col>
 </index>
</table>

<table name="task_tags">
 <field name="task_id" type="I" size="5">
  <KEY/>
 </field>
 <field name="tag_id" type="I" size="5">
  <KEY/>
 </field>
 <index name="task_id_tags">
  <UNIQUE/>
   <col>task_id</col>
   <col>tag_id</col>
 </index>
</table>

This db table change is IMHO a better start for the tag feature and can later more easily extended without brain damage of the developer.
(like additional fields or other tag related tables like "tag_translation" or "tag_synonym".)

I start with a field class in tags, which can contain a string of css classes.
When having a standard set of cssclasses for tag styling (lets say 10 colored slightly round edged with background and 10 that show an icon :before or :after tagname), these can be easy combined by the user and look nice.

Since today the basic tag feature is working the way I had in mind.

What still is missing:

1. styling by css and user interface for that. But you can still

address each tag with .tag.t123 in css if you can't wait and know the internal id of the tag (the tags are written as

<i class="tag t123">tagname</i>

1. autocompletion and autoformating when typing in tags input field

Edit 2015-11-12: modified for changed class scheme class="tag t123"

Hi Peter and others,

Before starting, I have some questions about this feature:

• Do you already have some design tools in mind for admin project part?
• We should define a permission to add a new tag "add_tag"? (show/hide tabs on project management, etc...)
• We should define a permission to use tag "use_tag"? (show/hide tag field on task_edit, etc...)
• Maybe seeing tags should be a permission "see_tag"?
• We should consider tagging/untagging a task as a modification, for notifying and reports?

What do you think about those?

"Do you already have some design tools in mind for admin project part?"

As starting point I think we can go this way:

• Show the current style of the tags on the tag management lists. (with ids, so easy for css writers)
• I added a themes/CleanFS/_tags.css as hint how to write the tags.css
• add a text input field to the tag list item row (class) in admin and project tags settings. At first user just input "tbicycle tgreen" there for a green tag with a bicycle icon. (tbicycle and tgreen are predefined for instance in tags.css (Maybe generate a dropdown-select of available tag classes as hint + adds the made selection to the text input on select by a few lines of javascript for convenience)

Adding the permissions you mentioned seems logic. But we have still so much permissions (nearly 30 per install and per project)

Before going tag permissions I would prefer implementing search/filtering by tags.
The creation of new tags can also be denied in the project settings, so we still have some control over tags.

"We should consider tagging/untagging a task as a modification, for notifying and reports?"

Yes, any add/remove of tag is a modification, so logging and notification should be made. But notification on change is incomplete also in other areas in Flyspray, so there is still enough work (see includes/modify.inc.php for example TODOs).

One uprising problem is that the more complete the notification system gets, the more spammy the notifications could be to the users, especially with the "quickedit"-feature. One possible solution to that would be grouping notifications together if requested by user (e.g. a user setting "send only 1 summary of changes per day for a task/ a project". But that's another story...