User Tools

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

Site Tools


mantisbt:global_categories_requirements

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

Phase 1: Using Category ID's

This is probably the most difficult and error-prone phase of the entire process, involving a completely new approach to storing and working with categories as entities. It will involve changes to many API's, as well as a special conversion process in admin/schema.php to change the database schema to fit the new paradigm.

Phase 2: Add Global Categories

Building on the work from phase 1, global categories will be supported using the special Project ID value '0' to denote independence from specific projects. Projects themselves will also need to gain a new value/flag inherit_categories (default to true) to determine if issues for that project can be set to global categories.

Phase 3: Add Catergory Inheritence

The final main phase will be the introduction of category inheritence between projects. The inheritance hierarchy will gain its own inherit_categories value (default no), to indicate that its issues can be set to the parents' categories.

Database Changes

Phase 1

This will be a multi-step process consisting of the following changes:

  • create mantis_category_table:
    • id int(10) primary key, with auto_increment flag
    • project_id int(10) index, value 0 will represent global categories.
    • name varchar(100)
    • status tinyint(4) index
    • user_id int(10)
  • modify mantis_bug_table
    • add category_id int(10) as foreign key to mantis_category_table
  • run custom upgrade function that will find existing categories, and create entries in new format
  • run custom upgrade function that will convert bugs' category value to category_id
  • modify mantis_bug_table
    • delete category column
  • delete mantis_project_category_table

Phase 2

  • modify mantis_project_table
    • add inherit_categories tinyint(4) to denote project will inherit global categories

Phase 3

  • modify mantis_project_hierarchy_table
    • add inherit_categories tinyint(4) to denote project will inherit categories from parent

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.txt · Last modified: 2008/10/29 04:25 by 127.0.0.1

Driven by DokuWiki