Nicer handling of bugtraq properties

[borzwazie@…]

It would appear that Trac partially supports Subversion bugtraq properties, useful for linking changesets back to the issue tracking url. However, when you add these properties, the output looks like this:

Added Subversion bugtraq properties to repository. bugtraq:message "#1"

While the #1 is correctly linked back to the issue, it's because Trac is using the built-in regex to link back. If the full bugtraq properties were read correctly, the Subversion repository would provide this information.

try setting the following properties on a Subversion repository (be sure to do this recursively):

bugtraq:label #
bugtraq:url ​http://localhost/cgi-bin/trac.cgi/ticket/%BUGID%
bugtraq:message "#%BUGID%"
bugtraq:number true
bugtraq:warnifnoissue false

If you connect to a subversion repository with a tool like TortoiseSVN, you'll be able to click on the defect number and link directly back to the issue in Trac.

Full support of this in Trac would be a nice enhancement.

[Christian Boos]

See also #1601, which proposes a framework for handling this kind of enhancements.

I'm also beginning to think that simply associating MIME-Types to properties would probably already be a good step forward. In that perspective, declaring the bugtraq:message property to be of type text/x-trac-wiki would be enough.

(and for #1896, we could associate svk:merge to application/octet-stream to simply hide it, and to application/x-svk-merge for a dedicated processing in the appropriate Mimeview renderer)

[Matthew Good]

cboos: the point of this ticket is that rendering the bugtraq:message property with the Trac Wiki syntax is not sufficient since it doesn't honor the other bugtraq properties which may refer to an external bug tracking system. So, rendering it for the mime type text/x-trac-wiki is not going to solve this issue.

I don't really see any benefit to mapping other SVN properties into mime types since it seems like we'd need to come up with some bogus mime type for most of the different properties. It would simply be cleaner to just use the property names as the keys for mapping them to an appropriate renderer. The property viewer API could be patterned after the mime viewer API, but I don't think it really lends itself to reuse.

It will also be necessary to deviate a bit from the mime viewer API since as seen with bugtraq it may not be possible to render each property on it's own, since rendering bugtraq:message also requires knowing the other 5 properties mentioned above.

[Christian Boos]

In the example from the ticket description, the other bugtraq properties were actually set to point to Trac's ticket system, which I guess could be made the default if the bugtraq:url is not set. But I see your point.

In the render method, we should actually get a dictionary of property name and values.

[Christian Boos]

For further reference, the issue tracker interoperability spec can be found there: ​http://guest:guest@tortoisesvn.tigris.org/svn/tortoisesvn/tags/version_1.2.0/doc/issuetrackers.txt

[borzwazie@…]

I was assuming that if one was running Trac that you'd want to point it to the built-in issue tracking, but the point is well-made that it might actually point to some other tracker. I don't think it really matters, provided the repository admin isn't weird enough to try something like that.

there's no facility within Trac to create or admin repositories (maybe another feature request?) so the only way that's going to get in there is if the svn admin sets it.

subversion will let you create any property you want (aside from a few reserved names I think), so maybe if you want to turn "off" the original trac tracking functionality and use the subversion bugtraq instead, have the user create a custom property on the repository that you'd look for and then read the bugtraq properties instead of using the built-in regex. the property need not even be recursive, you could simply set it at the top of the project tree.

[Christian Boos]

(changing the status, as I've not actually started to work on that yet)

[Christian Boos]

See also how to configure TortoiseSVN so that you can link back to Trac (0.11dev ≥ r4239) from Tortoise's revision log.

[anonymous]

Replying to cboos:

See also how to configure TortoiseSVN so that you can link back to Trac (0.11dev ≥ r4239) from Tortoise's revision log.

Replying to how to configure TortoiseSVN:

Implemented in r4239.

Now the TortoiseSVN's ​bugtraq:url property could be configured to point to one of these:

• <your-trac-url>/intertrac/ticket:%BUGID%
• <your-trac-url>/query?id=%BUGID%

In addition, the bugtraq:logregex property could be set to:

(?:ticket:|#)\d+(?:[-:]\d+)?(?:,\d+(?:[-:]\d+)?)*
\d+(?:[-:]\d+)?(?:,\d+(?:[-:]\d+)?)*

in order to match the regexps now used by Trac.

What I would actually love to see, is to have Trac itself actually use the bugtraq:logregex setting, or probably better, to allow the changing of the regex used to identify ticket id's in trac.ini.

Take this regex for example (is what I use):

[Ii]ssues? (#(\d+)(,? ?#(\d+))*( [aA][nN][dD] #(\d+))?)
(\d+)

[Christian Boos]

Milestone 1.0 deleted