Edgewall Software
Modify

Opened 13 years ago

Last modified 11 months ago

#3718 new enhancement

Trac should use HTTP 301 Moved when milestones get renamed

Reported by: daniel.connor@… Owned by:
Priority: high Milestone: next-major-releases
Component: general Version: 0.9.6
Severity: major Keywords: redirect rename tracobject consider
Cc: Branch:
Release Notes:
API Changes:

Description

  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.

Attachments (0)

Change History (6)

comment:1 by Christian Boos, 13 years ago

Keywords: redirect tracobject added

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

comment:2 by Christian Boos, 13 years ago

Keywords: rename consider added
Milestone: 1.0

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.

comment:3 by Christian Boos, 10 years ago

Milestone: 1.0next-major-0.1X

#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 ;-)

comment:4 by Christian Boos, 9 years ago

Priority: normalhigh
Severity: normalmajor

comment:5 by Christian Boos, 7 years ago

Type: defectenhancement

comment:6 by Ryan J Ollos, 4 years ago

Owner: Jonas Borgström removed

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
The ticket will be disowned. Next status will be 'new'.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.