mantisbt:tagging_requirements
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
mantisbt:tagging_requirements [2007/07/27 23:26] – Initial configuration thresholds jreese | mantisbt:tagging_requirements [2008/10/29 04:25] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 8: | Line 8: | ||
Because of the ' | Because of the ' | ||
+ | |||
+ | |||
===== 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 | + | 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 |
- | 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. | ||
+ | ==== 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. | ||
+ | ==== Tag Viewing ==== | ||
+ | |||
+ | When viewing a page for a specific tag, the user should be shown information about the tag, including a 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 ' | ||
+ | |||
+ | |||
+ | ==== 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. | ||
+ | * 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 '' | + | * Create '' |
- | * **id int(10)** with // | + | * **id int(10)** |
- | * **name varchar(100)** | + | * **user_id int(10)** |
+ | * **name varchar(100)** | ||
* **description text** | * **description text** | ||
+ | * **date_created datetime** | ||
+ | * **date_updated datetime** | ||
+ | |||
+ | * Create '' | ||
+ | * **bug_id | ||
+ | * **tag_id | ||
+ | * **user_id int(10)** | ||
+ | * **attach_date datetime** | ||
+ | |||
+ | |||
- | * Create '' | ||
- | * **bug_id | ||
- | * **tag_id | ||
===== Configuration Changes ===== | ===== Configuration Changes ===== | ||
+ | * Configuration settings | ||
+ | * '' | ||
* New threshold configurations (default access) | * New threshold configurations (default access) | ||
* '' | * '' | ||
* '' | * '' | ||
* '' | * '' | ||
+ | * '' | ||
* '' | * '' | ||
* '' | * '' | ||
+ | * '' | ||
+ | |||
+ | |||
===== 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 " | ||
+ | * I would have " | ||
+ | * 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' | ||
+ | * How are we going to incorporate tags in pages like: View Issues, Print Issues, My View, and CSV export. | ||
+ | * Are we going to report by tags? The same way we report by categories? | ||
+ | * How are users going to define the rules for auto-tagging? | ||
+ | * With regards to auto-tagging, | ||
+ | * 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. | ||
+ | * What will happen when a user is deleted? | ||
+ | * We should add group actions to add/remove tags. (vboctor) | ||
+ | |||
+ | **Second Review by vboctor:** | ||
+ | * Add ' | ||
+ | * I see no need for this. For comparison, mantis_project_user_list_table uses a PK of the two ids. (jreese) | ||
+ | * Add ' | ||
+ | * 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)