New 'Roadmap' module

[daniel]

cmlenz proposes an excellent addition, a Roadmap module.

Full description at:

​http://www.informatik.fh-wiesbaden.de/~clenz001/misc/trac_roadmap/

[Christopher Lenz]

Okay, here's my iteration plan for this story (very rough):

1. Basic roadmap module implementation
   • Add 'Roadmap' and 'Milestone' modules to source:trunk/trac/core.py​
   • Add the following permissions to source:trunk/trac/perm.py​
     • ROADMAP_VIEW
     • ROADMAP_ADMIN
     • MILESTONE_VIEW
     • MILESTONE_CREATE
     • MILESTONE_MODIFY
     • MILESTONE_DELETE
   • Basic implementation of source:trunk/trac/Roadmap.py and source:trunk/trac/Milestone.py
   • Add the templates source:trunk/templates/roadmap.cs and source:trunk/templates/milestone.cs
   • Add a new CSS style sheet as source:trunk/htdocs/css/roadmap.css that will be used by both the milestone and the roadmap view
   • No modifications to the database schema at this point: this means that milestones will be addressed by their name in the URL, for example /trac/milestone/milestone1, and milestones description will not yet be available

2. Add milestone management/administration functions
   • Add a 'Create New Milestone' action to the roadmap view
   • Add 'Edit This Milestone' and 'Delete This Milestone' actions to the milestone view
   • Implement a form that handles milestone creation and editing

3. Introduce milestone IDs and descriptions
   • Extend the database schema of the milestone table so that the primary key is an integer 'id' column, and add a 'description' text column.
   • Change the ticket table, and maybe the ticket_change table, so that milestones are referenced by ID instead of their name (not sure about that yet, though)
   • If the point above is done, adjust the ticket form and form handling to reference milestones by ID
   • Add/modify a database upgrade script (source:trunk/trac/upgrades/db4.py​)
   • Extend the form for editing milestones so that a wiki-formatted description can be entered/modified.
   • Milestone URLs now contain the ID instead of the name, for example /trac/milestone/11

4. Investigate/implement further enhancements:
   • Add linking to reports that list the open/active tickets for a milestone (and optionally component)
   • Add a "Show Past Milestones" action to the roadmap view (by default only non-completed milestones are displayed)
   • Anything else?

[Christopher Lenz]

A part of iteration 2 that I forgot would be to change or possibly even remove functionality in trac-admin that is related to milestone management.

[Christopher Lenz]

First iteration was checked in with [577].

[daniel]

A few ideas:

• Completed milestones could be pushed to the bottom of the page. Maybe not a good idea considering the chronological order/nature of milestones.

• Completed milestones could be displayed differently; e g just say something like "Milestone completed" rather than showing all tickets, progressbar and stuff. Saves some real-estate.

[Christopher Lenz]

In iteration 1 you should actually never see completed milestones. What is shown are all milestones that either have (a) no date set or (b) a date that is in the future. So the definition of a "completed" milestone is that its date has been reached.

Displaying completed/past milestones is planned for iteration 4.

[jamesm@…]

Ticket #440 touches on some things that are related to Roadmap.

[balk@…]

I'd recommend changing the header "percent completed" to "tickets completed". "Percent completed" doesn't really say percentage of what. And it's obvious it's percentage from the percentage-sign anyway.

[Christopher Lenz]

Iteration 2 status is tracked by #446.

[Christopher Lenz]

I've been thinking about the URL addressing scheme for milestones. The plan for iteration 3 is to introduce integer IDs as primary keys for the milestone table. However, that results in meaningless URLs.

Currently, if milestones are named in a URL-compatible manner (which is not being checked yet), you get URLs such as

​http://projects.edgewall.com/trac/milestone/0.7.1

which is quite nice I believe. Migrating to integer IDs would mean losing this URL readability.

An alternative to introducing an integer ID would be to keep the milestone name as the primary key and use it in the URL, but to add a 'Title' or 'Display name' column that could take a longer name that does not need to be URL-compatible (such as 0.7 'Fulci').

The downside of that approach would be URL persistence: if a milestone gets renamed (say from 0.7.1 to 0.7.1.0 or whatever), then links to the old milestone would get 404s. There would be ways to avoid that (by remembering the old names and causing permanent redirects), but that could get messy.

Any thoughts?

[jamesm@…]

I realize its ugly, but I think that the ability to link to the milestone outweighs the benefits of a pretty-url. I would say go with a fixed integer (like tickets do) and let the user assign a name/descrption to the fixed integer. I think that the linking throughout Trac/outside Trac is more important.

If #364 is for tickets and [400] is for Changesets, what notation will milestones use? [M1]?

[Christopher Lenz]

The roadmap module is pretty much complete now, as of [852]. Remaining shortcomings should go in separate tickets.