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 22:22] – jreese | mantisbt:global_categories_requirements [2008/10/29 04:25] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 12: | Line 12: | ||
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. | 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 ===== | ===== Proposed Approach ===== | ||
Line 26: | Line 28: | ||
[Child] Language | [Child] Language | ||
- | Individual projects should be able to choose if they should inherit parents' | + | ==== 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 | ||
+ | |||
+ | ==== Phase 2: Add Global Categories ==== | ||
+ | |||
+ | Building on the work from phase 1, global categories | ||
+ | |||
+ | ==== Phase 3: Add Catergory Inheritence ==== | ||
+ | |||
+ | The final main phase will be the introduction of category inheritence between projects. | ||
Line 32: | Line 45: | ||
===== Database Changes ===== | ===== Database Changes ===== | ||
- | | + | ==== Phase 1 ==== |
- | * **project_id** | + | |
- | * **category** field on '' | + | This will be a multi-step process consisting of the following changes: |
- | * add **inherit_categories_global | + | |
- | * add **inherit_categories_parents | + | * create '' |
+ | | ||
+ | * **project_id | ||
+ | * **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 convert bugs' **category** value to **category_id** | ||
+ | * modify '' | ||
+ | * delete **category** column | ||
+ | * delete '' | ||
+ | |||
+ | ==== Phase 2 ==== | ||
+ | * modify '' | ||
+ | | ||
+ | |||
+ | ==== Phase 3 ==== | ||
+ | | ||
+ | | ||
- | * Admin update script will need to add **id** values to each category, and update all bugs to use the new **category_id** | ||
- | ===== Configuration Changes ===== | ||
===== 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.1185589359.txt.gz · Last modified: 2008/10/29 04:31 (external edit)