Table of Contents

Global Categories Requirements

Author: John Reese


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:

[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:

Phase 2

Phase 3


Any feedback should be placed below.

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