User Tools

  • Logged in as: anonymous (anonymous)
  • Log Out

Site Tools


mantisbt:tagging_requirements

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
mantisbt:tagging_requirements [2007/07/27 23:26] – Initial configuration thresholds jreesemantisbt:tagging_requirements [2008/10/29 04:25] (current) – external edit 127.0.0.1
Line 8: Line 8:
  
 Because of the 'metadata' nature of tagging, it would not be primary method of classification for issues (which would still be left to categories), and could allow for lower permission requirements for tagging reports, such as allowing any registered reporters to add tags at any time.  It could also allow for potential custom auto-tagging features, where certain tags could be automatically attached to any bug containing special characteristics, like a report with version control checkins. Because of the 'metadata' nature of tagging, it would not be primary method of classification for issues (which would still be left to categories), and could allow for lower permission requirements for tagging reports, such as allowing any registered reporters to add tags at any time.  It could also allow for potential custom auto-tagging features, where certain tags could be automatically attached to any bug containing special characteristics, like a report with version control checkins.
 +
 +
  
  
 ===== Proposed Approach ===== ===== Proposed Approach =====
  
-All tags will be stored in a database table, with a separate table containing foreign key links between bugs and tags.  There should be a separate portion of the bug view to show all tags currently attached to a bugas well as an input box to enter further tags to be added Tags entered in the form should be separated by commasso that multi-word tags are possible.  Auto-complete should be simple substring comparisoneither against a JavaScript list of popular tags, or using an AJAX query to the database.  The user should be able to click a link that willin some fashionshow a list of all tags in use, using pagination if necessary + All tags will be stored in a database table, with a separate table containing foreign key links between bugs and tags. A tag may only be attached once to each report. By default, anyone with reporter access will be able to create and attach tags to a reportand will be able to detach only the tags they attached. Developers will have access to edit tags and detach any tags from bugsBy default, tags will be separated by commas so that multi-word tags can be usedbut it can be configured to use spacesor any other characterinstead.
  
-When viewing tags already attached to a report, a link should be available to a page listing more information about the keyword, including the ability to enter or edit a description.  The tag's page should also include links to various searches filtered on the tag, such as all open issues, all resolved issues, etc. 
  
 +==== Bug Viewing ====
 +
 +When viewing bug reports, there should be a separate portion of the bug view to show all tags currently attached, as well as an input box to enter further tags to be added.  Auto-complete should be used with simple substring comparison, either against a static JavaScript list of popular tags, or using an AJAX query to the database.  The user should also be able to click any attached tag to view a page with more information.
 +==== Tag Viewing ====
 +
 +When viewing a page for a specific tag, the user should be shown information about the tag, including a description, the user who created it, when it was created and last updated, how many bugs it has been attached to, and five tags that were attached the most to the same bugs.  If the user has high enough access (see threshold configuration), then they should be able to edit the tag's name and description.
 +
 +
 +==== Filters ====
 +
 +When using the filters page in normal mode, a simple multi-select box containing a list of tags will be used to choose what tags to filter on.  In advanced mode, a free text input will be used, where the user can list out tags to filter on, in the form '+tag', 'tag', or '-tag'. In this manner, any tag noted with a '+' **must** be attached to any resulting bug, any tag noted with '-' **must not** be attached to any resulting bug, and resulting bugs must have **any** of the un-denoted tags attached, but not necessarily all of them.  The system will use a case-insensitive search on existing tags, as well as looking for existing tags with or without a trailing 's' to match and use existing tags before creating new and redundant tags.
 +
 +
 +==== Management Decisions ====
 +
 +  * If a tag has been removed from all reports that it has been attached to, it should not be removed from the database for history and data reasons; it should be manually removed by someone with appropriate access.  
 +  * When renaming or deleting tags, associated bugs should have their histories appropriately updated with an event noting the change: noting that the tag has changed names (renaming) or has been removed (deleted).
 +
 +==== Future Possibilities ====
 +
 +The initial implementation will not provide these features, but they could be included in future updates:
 +  * Using tag clouds for reporting and other views.  This is a planned addition after the first implementation.
 +  * Auto-tagging reports based on unique actions or events, such as source control submission, etc.
 +  * HTML metatag keyword filling from tags.
  
  
 ===== Database Changes ===== ===== Database Changes =====
  
-  * Create ''tag_table'' with fields: +  * Create ''mantis_tag_table'' with fields: 
-    * **id int(10)** with //auto_increment// flag +    * **id int(10)** primary key, with //auto_increment// flag 
-    * **name varchar(100)** +    * **user_id int(10)**  
 +    * **name varchar(100)** index
     * **description text**     * **description text**
 +    * **date_created datetime**
 +    * **date_updated datetime**
 +
 +  * Create ''mantis_bug_tag_table'' with fields:
 +    * **bug_id  int(10)** primary key with **tag_id**
 +    * **tag_id  int(10)** index
 +    * **user_id int(10)**
 +    * **attach_date datetime**
 +
 +
  
-  * Create ''bug_tag_table'' with fields: 
-    * **bug_id  int(10)** 
-    * **tag_id  int(10)** 
  
  
 ===== Configuration Changes ===== ===== Configuration Changes =====
  
 +  * Configuration settings
 +    * ''tagging_separator'' (default to ','), use trim() on each tag after explode() to account for "word, word" etc.
   * New threshold configurations (default access)   * New threshold configurations (default access)
     * ''tagging_view_threshold'' (VIEWER) to see tags attached to bugs     * ''tagging_view_threshold'' (VIEWER) to see tags attached to bugs
     * ''tagging_attach_threshold'' (REPORTER) to attach tags to bugs     * ''tagging_attach_threshold'' (REPORTER) to attach tags to bugs
     * ''tagging_detach_threshold'' (DEVELOPER) to remove tags from bugs     * ''tagging_detach_threshold'' (DEVELOPER) to remove tags from bugs
 +    * ''tagging_detach_own_threshold'' (REPORTER) to remove tags attached by the same user
     * ''tagging_create_threshold'' (REPORTER) to create new tags when attaching to bugs     * ''tagging_create_threshold'' (REPORTER) to create new tags when attaching to bugs
     * ''tagging_edit_threshold'' (DEVELOPER) to edit tag names and descriptions     * ''tagging_edit_threshold'' (DEVELOPER) to edit tag names and descriptions
 +    * ''tagging_edit_own_threshold'' (REPORTER) to edit tags created by the same user
 +
 +
  
 ===== Feedback ===== ===== Feedback =====
 +
 +Any feedback should be placed below.
 +
 +**First Review by vboctor:**
 +  * By default table names start with mantis_ prefix (vboctor)
 +  * Consider capturing the tag creation date and last update date in the tag definition table. (vboctor)
 +  * Include a section about the how tagging will generate issue history events. (vboctor)
 +  * In the bug-tag table, include the timestamp where the relationship was added and by who?  This will allow implementing features like "detach_own_threshold". (vboctor)
 +  * I would have "space" as the tag separate rather than "," This will also simplify the display of such tags in places other than the View Issues page where we are compact in space. (vboctor)
 +  * What about filtering by tags?  For example, what are all issues that have tagA and tagB.  We can even go further with stuff like tagA but not tagB.  Is it going to be a free text (+tagA -tagB)? or a multi-select list box with all tags? (vboctor)
 +  * What about supporting public / private tags?  By public / private I mean the same as issues and issue notes, where a higher threshold is needed to view private ones.  These can be internal tags that the company doesn't want customers to see.  History entries related to these will also have to be filtered out for users who don't have access. (vboctor)
 +  * How are we going to incorporate tags in pages like: View Issues, Print Issues, My View, and CSV export.  In some of these cases we need to come with innovative ways due to compact space.
 +  * Are we going to report by tags?  The same way we report by categories?  Graphs, Summary page? (vboctor)
 +  * How are users going to define the rules for auto-tagging?  Custom functions is one option, do you have others in mind?  We can use the existing custom functions that are used when creating and updating issues. (vboctor)
 +  * With regards to auto-tagging, who will be the owner of the history event?  We might need to use a special user id for that. (vboctor)
 +  * How are we going to create tags on the fly?  What about the properties of the tag other than its name. (vboctor)
 +  * Define what will happen when a tag is renamed or deleted. (vboctor)
 +  * In the view issue page, we should consider including the tags as part of the meta keywords.  This will help with "some" of the search engines (I don't think Google use them). (vboctor)
 +  * What will happen when a user is deleted?  What will happen to the tags assigned by him?  I think we should keep them, we should handle this the same way this is handled in other places.  I think we keep the user id, and refer to the user as user10 or whatever the id was. (vboctor)
 +  * We should add group actions to add/remove tags. (vboctor)
 +
 +**Second Review by vboctor:**
 +  * Add 'id' field to 'mantis_bug_tag_table'
 +    * I see no need for this. For comparison, mantis_project_user_list_table uses a PK of the two ids. (jreese)
 +  * Add 'user_id' field to 'mantis_tag_table'.
 +  * Define the indices.
 +  * We talked about a tag cloud (put it in future possibilities if you are not planning to include it in initial implementation).
mantisbt/tagging_requirements.1185593168.txt.gz · Last modified: 2008/10/29 04:31 (external edit)

Driven by DokuWiki