Various ticket fields don't like leading or trailing /

[rblank]

As an example, create a milestone where the name either starts or ends with a /. It will be visible in the roadmap, but clicking on the link will lead to an error, saying that the milestone cannot be found. The same problem applies to other enumerated fields like components, priorities or versions, when edited in the admin module.

The problem is due to the roadmap module creating links to milestones using req.href.milestone(milestone_name), and href stripping leading and trailing slashes at this location. The same analysis applies to the admin module.

I'm not sure if the solution is to build the milestone and admin links differently, or to remove the automatic stripping in Href. Opinions welcome.

[cboos]

Same issue for Wiki page names, one could eventually create (programatically) a WikiPageName ending with a '/', but we won't be able to access it through the web interface, because of the redirect.

The only difference is that the web interface prevent creating such Wiki pages, but allows it for Milestones. So I think we should keep the links as they are and add some safeguards (i.e. strip trailing '/') when creating the milestones.

[rblank]

There's another reason why trailing slashes are forbidden in wiki page names: the attachments module displays the list of attachments for a wiki page- (or any other resource) when the URL has a trailing slash, like /attachments/wiki/WikiStart/. AFAIK, this is the only location in Trac where a trailing / is significant.

I don't think it is necessary to strip the slashes in milestone and other enum values. I have tried an experimental patch where the links are constructed so that the / are not stripped, and this fixes the problem (and everything else continues working). But I may be missing something.

[rblank]

BTW, shouldn't resource names containing arbitrary characters be passed as query arguments, like /milestone?name=My%20milestone ? Or does this break some kind of hierarchy convention?

[rblank]

Closed #6303 as a duplicate.