3 | | Here is a proposal for the specifications of Trac Subtickets. See related tickets #31, #886, #2344, #3003, #6328 and #7422. I have not discussed viewing ticket hierarchies because I think this can be a feature added after these are completed. Moreover, I think that we should minimise the impact of these changes so that most users will hardly notice the feature was added (in case they don't want it). Therefore, parent and child tickets should be treated exactly the same as tickets are now, with the few simple and basic modifications described below. |
| 3 | Here is a proposal for the specifications of Trac Subtickets. See related tickets #31, #886, #2344, #3003, #6328 and #7422. I have not discussed viewing ticket hierarchies because I think this can be a feature added after these are completed. Moreover, I think that we should minimise the impact of these changes so that most users will hardly notice the feature was added, in case they don't want it. Therefore, parent and child tickets should be treated exactly the same as tickets are now, with the basic modifications described below. |
37 | | === Milestone Replacement === |
38 | | Whatever changes we make in an effort to genericise milestones, we should ensure that the result is backwards-compatable with what people are using now for milestones. |
39 | | * Roadmap Page |
40 | | On the roadmap page, we should display the "subtickets" tab (minus the sidebar, described above) of all tickets that have no parent. We can easily change milestones into parent tickets on upgrade, but a problem arises when a ticket has no milestone. In this case, the ticket clearly should not be displayed as a parent ticket on the roadmap page. I propose we create a special parent ticket for this with name "None" or "Future". This should also be the default for all newly created tickets so they do not automatically become top-level tickets. Then all tickets not assigned to a milestone on upgrade would be subtickets of the Future ticket, which will probably be acceptable to most users because it has a maximum impact of adding a single milestone. |
41 | | * Milestone Details Page |
42 | | This page is simply the "subtickets" tab described in "Viewing Parent Tickets" |
43 | | * Milestone Dates |
44 | | There is a problem here. Tickets currently do not have a due date, though we could fake this by adding a custom field onto all parent tickets. I would appreciate thoughts on this. Or perhaps we could add a due date to all tickets. I think this warrants some feedback from users using the milestone feature right now. |
| 32 | A little off-topic, but I think that the progress bar calculation should be extendible so plugins can change how |
| 33 | this works, if they want to work off different fields see TimeTracking. |
46 | | [a due datetime on a ticket would be fine - ''couldn't that be easily done when ticket #1942 is solved?''] |
| 35 | == Milestone Replacement |
| 36 | |
| 37 | Whatever changes we make to unify milestones, we should ensure that the result is backwards-compatible with what people are using now for milestones. |
| 38 | |
| 39 | Roadmap Page:: |
| 40 | On the roadmap page, we should display the "subtickets" tab (minus the sidebar, described above) of all tickets that have no parent. We can easily change milestones into parent tickets on upgrade, but a problem arises when a ticket has no milestone. In this case, the ticket clearly should not be displayed as a parent ticket on the roadmap page. I propose we create a special parent ticket for this with name "None" or "Future". This should also be the default for all newly created tickets, so they do not automatically become top-level tickets. Then all tickets not assigned to a milestone on upgrade would be subtickets of the Future ticket, which will probably be acceptable to most users, because it has a maximum impact of adding a single milestone. |
| 41 | |
| 42 | Milestone Details Page:: |
| 43 | This page is simply the "subtickets" tab described in "Viewing Parent Tickets". |
| 44 | |
| 45 | Milestone Dates:: |
| 46 | There is a problem here. Tickets currently do not have a due date, though we could fake this by adding a custom field onto all parent tickets. Or perhaps we could add a due date to all tickets. I think this warrants some feedback from users using the milestone feature right now. [A due datetime on a ticket would be fine - ''couldn't that be easily done when ticket #1942 is solved?''] |