All pending tasks and bugs related to the website.

FS#4169 - [website] redirect trac links to bug tickets back to flyspray

Attached to Project: Website
Opened by Nathanael Rebsch (dihedral) - Monday, 18 October 2010, 11:33 GMT
Last edited by Remko Bijker (Rubidium) - Friday, 22 October 2010, 21:11 GMT
Type Feature Request
Category Interface
Status New
Assigned To No-one
Operating System All
Severity Low
Priority Normal
Reported Version other
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No



The commit message shown at refers to  FS#4167 , which is turned into a link, however it links to The actual task though is found at /task/4167

A redirect, or amended link in the trac template would be useful.
This task depends upon

Comment by Remko Bijker (Rubidium) - Wednesday, 22 December 2010, 22:45 GMT
I tried to find it, but couldn't find where the template has to be updated. Do you have any clue?

Even then, editting some files that are managed by the package manager might not be such a good idea when (security) upgrades are happening. Also tried to get the webserver to redirect that, but that attempt failed; probably due to me just not getting it.
Comment by Nathanael Rebsch (dihedral) - Thursday, 23 December 2010, 03:18 GMT
for apache2, either in .htaccess file, or in the virtual hosts config section:

RedirectMatch permanent ^/svn/ticket/(\d+) /task/$1

by the looks of it similar works for nginx:

server {
redirect ^/svn/ticket/(\d+) /task/$1

hope this helps
Comment by AnthonyVDG (avd) - Saturday, 01 January 2011, 12:41 GMT
I think there is a missing $ at the end of the regex:

Comment by Nathanael Rebsch (dihedral) - Saturday, 01 January 2011, 13:40 GMT
the $ is not needed, it only marks the end of the string which means the following:

/svn/ticket/5 <- matches
/svn/ticket/5/ <- does not match

in the unlikely event of there being an external link (over which we have no control) an added char at the end of the url can render the redirect to not match, which i assume is something we do not want ;-)
Comment by Patric Stout (TrueBrain) - Sunday, 02 January 2011, 12:24 GMT
This is approaching the issue from the wrong side. Of course you can fix it up in the httpd, but this is not a durable solution (as we have noticed in the past). The solution should be in trac. But every time we patch it up to work as intended, some update or what ever fucks it up again. After doing it 3 times, you give up on it. It should be on the side of trac to not stupidly assume the bug-tracker will be in trac, and allow linking to some offsite bug-tracker. I believe this has been requested to trac many many times, but so far I haven't seen it implemented.

Either way, I see no use to 'fix' this problem on the httpd side again. Neither by modifying trac again.