Bugzilla – Full Text Bug Listing
| Summary: | [Coop] pluggable hyperlink policy support | ||||||
|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Jean-Michel Lemieux <jean-michel_lemieux> | ||||
| Component: | Mylyn | Assignee: | Mik Kersten <mik.kersten> | ||||
| Status: | RESOLVED DUPLICATE | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P4 | CC: | brockj, craig.pardey, ekuleshov, gunnar, mik.kersten, mlists, shawn.minto | ||||
| Version: | 0.3 | Keywords: | helpwanted | ||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Jean-Michel Lemieux
Created attachment 10170 [details]
patch
Note the excessive underlines at the line end when it is wrapped.
*** Bug 61457 has been marked as a duplicate of this bug. *** I'd like to suggest to add a generic default implementation that would allow to specify per-project configuration for the bug-parsing patterns as well as entry point url to bugtrack system web interface to query parsed bug. Silvio is leaving soon so not for 3.1 I'm interested in a more generic API, which would allow several 3rd party plug-ins to communicate with team providers. - Create associations on check-in/commit times - Generate touched files list for commit comments - Attach patches to bugs - Automatically resolve bugs on checkin/commit Possible API clients: Team.bugs (http://people.redhat.com/jpound/) Mylar.bugzilla (http://eclipse.org/mylar/dev.html) See some additional comments in bug 106862 https://bugs.eclipse.org/bugs/show_bug.cgi?id=106862 As Gunnar points out this would be very useful for Mylar. We already have a hyperlink listener for the Java source editor, which hyperlinks bugs in the same way as Bugzilla does (e.g. bug 106862 turns into a link). Clicking opens the bug in the bug editor that you have associated (either our bug editor or the internal browser). A straightforward way of doing this could be to make the revision comment pane a non-editable AbstractDecoratedTextEditor, and then provide us with an extension point for contributing a hyperlink listener. Then each bug tracking system could contribute a hyperlink listener. If it turns out that multiple listeners frequently want to highlight the same format, then it may be useful to have a prefs page for ordering them. But ideally they would be matching on different link formats, or there could be a mechanism for associating a resource/project with a particular bug tracking repository. As a part of this, it may also be desireable to add a default IHyperlinkDetector that works for URLs. This would have the effect of opening the URL in the internal browswer. It would enable pasting in links to things like test runs. But note that it will probably be necessary to allow this to be overridden in order to make it possible to open full URLs for bug reports in a bug report editor. (In reply to comment #7) > As Gunnar points out this would be very useful for Mylar. We already have a > hyperlink listener for the Java source editor, which hyperlinks bugs in the same > way as Bugzilla does (e.g. bug 106862 turns into a link). Clicking opens the > bug in the bug editor that you have associated (either our bug editor or the > internal browser). > > A straightforward way of doing this could be to make the revision comment pane a > non-editable AbstractDecoratedTextEditor, and then provide us with an extension > point for contributing a hyperlink listener. Then each bug tracking system > could contribute a hyperlink listener. If it turns out that multiple listeners > frequently want to highlight the same format, then it may be useful to have a > prefs page for ordering them. But ideally they would be matching on different > link formats, or there could be a mechanism for associating a resource/project > with a particular bug tracking repository. Mik, this is sounds really cool but it is also some kind of overkill for such use case. It isn't much longer to copy bug id and then paste into Mylar task filter box. Well, of couse if it would implement smart search as suggested here https://bugs.eclipse.org/bugs//show_bug.cgi?id=107085#c2 These are all interesting ideas. However, we are not planning to do any work in this area. If you create a patch that provides the funtionality you require, I would be happy to work with you with the goal of incorporating the required facilities into Team/CVS. Thanks Michael. As Eugene points out the current work-around is easy. If this becomes a frequently requested feature for us we will create the patch. (In reply to comment #11) > Thanks Michael. As Eugene points out the current work-around is easy. If this > becomes a frequently requested feature for us we will create the patch. Mik, just make sure it will also work for multiple issue providers and will leave an option to support not only CVS. ;-) Will do. I think that just means that our hyperlink detector will have to be aware of what repository a particular project is associated with, and have the plug-in that supports that repository contribute an "open report" action to the hyperlink detector. (In reply to comment #13) > ...I think that just means that our hyperlink detector will have to be > aware of what repository a particular project is associated with, and have the > plug-in that supports that repository contribute an "open report" action to the > hyperlink detector. Not just project! Editor can actually contain file revision from the resource history or even file opened from the CVS or SVN Repository explorer, so there will be no project around. In such situation it will be necessary to somehow find out what issue tracking system is used for current version control system repository. Anyways, shouldn't this issue be reassigned to Mylar project? It can be moved, as far as I'm concerned. I'll leave it up to Mylar to decide if they want it. Sure, we'll take this. We'll do the simple case first (single bug system), but will make sure the "open report" action is contributed by our Bugzilla plug-in so that another plug-in can contribute a different open action for a report. The binding between resource and bug repository can then be handled by that contributor. The ability to navigate from CVS Resource History entry to bug report is now supported in Mylar by an "Open Corresponding Report" action on the popup menu (http://eclipse.org/mylar/doc/new.html). That has the effect of finding a "bug <id>" reference in the commit message and using our Bugzilla Client's policy for opening those. If there is a URL in the commit message but no report, the URL will be opened in the internal browser (e.g. link to a Jira report). This can be made more extensible once there is a client. I'll leave this report open since it would be slightly nicer to have the commit entries highlight as hyperlinks (as bug IDs do in our extension to the Java Editor), but that would probably require changing the CVS Resource History view to support hyperlink providers. I somehow completely forgot about this issue and created new one with some prototyped patch that introduces new extension point in Team plugin. See Bug 153932 Since Mylar now provides and a hyperlink detector that works for any supported bug/task/issue task repository and uses this in its task editor, the key thing left here is to be able to add this detector to relevant text viewers, i.e. the History view's comments area. So marking as duplicate of Eugene's new new report. *** This bug has been marked as a duplicate of 153932 *** I just want to say here that my patch is quite different from what Zhiyong Liu created two years ago. -- use platform web browser to open url's -- default handler is matching http urls -- pluggable extension point for pluggin in special parsing and linking funcionality (e.g. detect bugs and open links with Mylar's editors) -- implemented support for this in history view, so by default it has only default handler, but will use any others as soon as they registered (e.g. by mylar) -- same delegation to handlers can be added to Subclipse/Subversive |