Trac should use HTTP 301 Moved when milestones get renamed

[daniel.connor@…]

1. Create a milestone "Example"
2. Add a ticket to the milestone
3. Subscribe to the RSS feed.
4. Edit the milestone, rename to "Changed Milestone"

Expected behaviour:
Trac 'knows' a milestone has been renamed, and does a 301 Moved response code. The client application / browser redirects, and the end user doesn't notice anything out of the ordinary

Actual:
Trac doesn't do this. milestone:"milestone name" links break, feeds break, and so much more.

Suggested:
A simple entry to a 'milestone (previous) names' table would fix this - when a milestone isn't known, the table is checked, and a 301 is sent with an updated location.

[cboos]

Interesting. This could perhaps be done for Wiki page renaming too.

[cboos]

OTOH, this would prevent to recreate a milestone which has previously be renamed, using the #4145 method. There would still be the WebAdmin for this, so the features are not incompatible.

[cboos]

#9168 suggested the use of numerical identifiers for milestone.

That would indeed solve the issue described in this ticket, but for reasons I explained in the other ticket, I think we can't really use internal ids for TracLinks. So the problematic of doing redirects remains valid until we rewrite the incoming Trac links to the milestone after it has been renamed. Even if the latter proves to be feasible, this wouldn't solve the problem for InterTrac references to that milestone present in other Tracs and even plain http: URLs that couldn't be recognized as links to the milestone, in the same Trac.

So a "redirect map" would perhaps be useful in any case (a bit similar to the urlmap proposed by Jan Schukat for renaming of special Wiki pages in ticket:1106#comment:121).

It could work like this:

• after a milestone rename, add an entry (oldname, newname) to that table, update existing entries having new = oldname with newname as well, so that we only have one level of indirection
• for requests to a milestone name which doesn't exist, we check if there's an entry in the redirect table for which old = name. If yes, we do a redirect to the corresponding new, otherwise it's the usual behavior (#4145)
• bookkeeping of the redirect table when a milestone is deleted, to clear the aliases if any (or even keep a deleted status?)
• when formatting a TracLinks to a redirected milestone, the tooltip could show the new name (now <newname>)
• when about to create a new milestone which happens to be a redirect, warn and ask for confirmation (ideally, showing the inbound links)

As usual, I'm now wondering if this wouldn't also make sense for other resources, especially Wiki pages, and be a more realistic solution than doing massive rewriting after renames... (and then what? automatically create new versions of pages?). Also, compared to the current solution of leaving a real redirect page behind, this would address the concern of polluting the TitleIndex (ticket:1106#comment:78). We wouldn't create real "redirect" milestones that would show up in the roadmap either ;-)