mantisbt:global_categories_requirements
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
mantisbt:global_categories_requirements [2007/07/27 15:20] – Intro and feedback jreese | mantisbt:global_categories_requirements [2008/10/29 04:25] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 6: | Line 6: | ||
Categories in Mantis are specific to a single project, and can only be used by issues in that project. | Categories in Mantis are specific to a single project, and can only be used by issues in that project. | ||
+ | |||
+ | |||
===== Current Approach ===== | ===== 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. | ||
+ | |||
+ | 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. | ||
+ | |||
+ | ==== Phase 2: Add Global Categories ==== | ||
+ | |||
+ | Building on the work from phase 1, global categories will be supported using the special Project ID value ''' | ||
+ | |||
+ | ==== Phase 3: Add Catergory Inheritence ==== | ||
+ | |||
+ | The final main phase will be the introduction of category inheritence between projects. | ||
+ | |||
+ | |||
+ | |||
===== Database Changes ===== | ===== Database Changes ===== | ||
- | ===== Configuration Changes | + | ==== Phase 1 ==== |
+ | |||
+ | This will be a multi-step process consisting of the following changes: | ||
+ | |||
+ | * create '' | ||
+ | * **id int(10)** primary key, with // | ||
+ | * **project_id int(10)** index, value //0// will represent global categories. | ||
+ | * **name varchar(100)** | ||
+ | * **status tinyint(4)** index | ||
+ | * **user_id int(10)** | ||
+ | * modify '' | ||
+ | * add **category_id int(10)** as foreign key to '' | ||
+ | * 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 '' | ||
+ | * delete **category** column | ||
+ | * delete '' | ||
+ | |||
+ | ==== Phase 2 ==== | ||
+ | * modify '' | ||
+ | * add **inherit_categories tinyint(4)** to denote project will inherit global categories | ||
+ | |||
+ | ==== Phase 3 ==== | ||
+ | * modify '' | ||
+ | * add **inherit_categories tinyint(4)** to denote project will inherit categories from parent | ||
+ | |||
+ | |||
===== Feedback ===== | ===== Feedback ===== | ||
Any feedback should be placed below. | 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. | ||
+ | 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. | ||
+ | * 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. | ||
+ | * 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? | ||
+ | * 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' | ||
+ | * Don't use long field names like ' | ||
+ | * 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. | ||
+ | * What will happen when a category is deleted? | ||
+ | * I would like to see a section about impact on Filters and another on Performance (if no impact on performance, | ||
+ | * 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? |
mantisbt/global_categories_requirements.1185564003.txt.gz · Last modified: 2008/10/29 04:31 (external edit)