User Tools

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

Site Tools


mantisbt:global_categories_requirements

This is an old revision of the document!


Global Categories Requirements

Author: John Reese

Introduction

Categories in Mantis are specific to a single project, and can only be used by issues in that project. But there are many times, especially in organizations with many different projects, that it would be very useful to have not only shared sets of categories, but inherited categories from parent projects as well. This would greatly simplify and automate multiple project administration.

Current Approach

In the current Mantis system, all shared categories must either be created or copied between projects and subprojects by hand. Modifying one category means manually modifying every other project that category exists in to reflect the same change. There is also no way to handle global categories other than to copy categories from one project to every other project. Adding a new project or subproject later means more work to copy categories to it as well.

Proposed Approach

Categories should be able to created in a global configuration and will be available for All Projects. When assigning a category to an issue, the category list should include all global categories, as well as categories from all parent projects (and parents' parent projects, etc.). Preferably, global categories and inherited categories should be separated from project-specific categories, and all categories listed should contain the associated project's name in brackets. For example, a category list could look like so:

General
Unknown
---
[Parent] Database
[Parent] Documentation
---
[Child] Interface
[Child] Language

Individual projects should be able to choose if they should inherit parents' categories or not, and if they should inherit global categories or not. Default settings would be to inherit globals, but not parents'.

Database Changes

  • add id int(10) field on project_category_table with auto_increment flag to keep unique category_id values.
  • project_id field on project_category_table will use value '0' to denote global categories that can be shared by all projects.
  • category field on bug_table will change to category_id int(10) as foreign key to project_category_table.
  • add inherit_categories_global tinyint(4) field on project_table to denote whether the project will inherit global categories .
  • add inherit_categories_parents tinyint(4) field on project_table to denote whether the project will inherit categories from parent projects.
  • Admin update script will need to add id values to each category, and update all bugs to use the new category_id

Feedback

Any feedback should be placed below.

  • I would suggest we split this feature into the following: (vboctor)
    • Use category ids.
    • Support global categories
    • Support category localization (did you consider this? would be nice if we can take this into consideration during requirements and design, even if we are not implementing it right away).
    • Support category inheritance. This will have to be consistent with other entities like versions, custom fields, etc.

Such split will allow us to start with the implementation faster, simplify the patches and make them easier to review, less conflicts, etc.

  • Note that a project can be a sub-project from multiple projects. For example, c is a sub-project of A and B. There are two issues here:
    • When the user select c as the current project and parent category inheritance is ON, which set of categories are you going to show? You probably need to identify the current project as a→c, or b→c rather than just c, to handle this scenario. This will have to be supported in filtering, etc. I am worried about the complexity involved here.
    • How will you allow c to inherit categories from A but not B? (vboctor)
  • Will the bugs without category (currently empty string) map to 0? (vboctor)
  • Are you going to replace bugs with category string that is not found any more (not sure if that is possible, but could be due to bugs in the paste) to be 0? (vboctor)
  • What about the history table? Once you rename a category, are you going to go back and update the history entries relating to reflect the new category name? (vboctor)
  • How are you going to handle moving issues between projects where the issue belongs to category in source project that is not shared with destination project? (vboctor)
  • We should use the same int length for category id like version id. I haven't verified if version used int(10). (vboctor)
  • Don't use long field names like 'inherit_categories_global' and 'inherit_categories_parents' since they are not supported by some of the databases. I don't know the exact size limits, but you may want to check the history of changes for schema.php you will find the renamed fields that will give you an indication of the max length. (vboctor)
  • I am not sure I agree with prefixing the categories with the project. (vboctor)
  • We have to be clear about the number of levels of inheritance we support. This should be consistent across the board with our sub-project support. We should disallow setting up deeper levels of sub-projects than we support. (vboctor)
  • What will happen when a category is deleted? Are you going to change all references to 0 or are we going to force users to rename all references first? (vboctor)
  • I would like to see a section about impact on Filters and another on Performance (if no impact on performance, then say so). Regarding filters, an example is that when View Issues is selected, we should probably show global categories as the option for “Category”, etc. (vboctor)
  • The support for category ids should be consistent with the support for version ids. So you might want to see how some scenarios are handled and mimic them in categories. (vboctor)
  • What are the implications on current graphs, summary page, etc. (vboctor)
  • What about exports like Word, Excel, CSV? For example, in CSV are we going to include project as part of the category? Is the concatenation going to be done by the client script or is the API going to provide two options for getting categories? (vboctor)
mantisbt/global_categories_requirements.1185608915.txt.gz · Last modified: 2008/10/29 04:31 (external edit)

Driven by DokuWiki