Community
Participate
Working Groups
Sometimes I'm asked to create a new bug from some comment. We can have a button together with the "reply", on each comment, where when clicked would open a new bug editor with the same attributes from the original one, with some template description like "Bug created from bug#XXX comment#YYY: {original-comment-here}".
A more powerful enhancement would be to be able to fork a new bug on another repository, e.g., let's say there is some discussion about subversion integration on mylar bugzilla, and then some idea emerges but it has to open a issue on subclipse issuezilla. The template on this case can link to the original comment URL. If you think it is worth to open a separate bug for this, I can do it after comment#0 is fixed ;)
(In reply to comment #1) > A more powerful enhancement would be to be able to fork a new bug on another > repository, e.g., let's say there is some discussion about subversion > integration on mylar bugzilla, and then some idea emerges but it has to open a > issue on subclipse issuezilla. The template on this case can link to the > original comment URL. > If you think it is worth to open a separate bug for this, I can do it after > comment#0 is fixed ;) Sounds like a good idea Willian. Perhaps comment#1 is the way to go where comment#0 is simply a special case of the target repository being the same as the originating report?
Isn't it nearly the same as creating issues from the Error Log view? If so, most of the code probably already there, including a workaround for web-based editors when details are copied to the clipboard.
I'm bumping this to P2 for now, because we have hade several bugs along this "flexible bug creation" theme (e.g. bug 154896) and should consider this in 2.0 planning.
Created attachment 79776 [details] patch I build a patch, but there is one thing left. In AbstractRepositoryTaskEditor.java method createNewBugHyperlink I only build the URL for repositoryKind == "bugzilla" because I do not know how to build this for the other repositories. If some on give me that information I will build a new patch. Maybe we should build that description in an overwrite method.
Created attachment 79777 [details] mylyn/context/zip
You can get task url using AbstractRepositoryConnector.getTaskUrl(String repositoryUrl, String taskId) there is no API for getting urls that include comments and present hyperlink detectors can't handle url pointers to comments (need a separate bug for that). So, I think for now it is better to leave comment out of url and just say it in text. BTW, it could be useful to be able to create issue only from selected text. And this action should be also available from the popup menu. Also it seems like this issue represent use case for bug 203798. Another use case is create template from selected comment text, see bug 201028.
What do other's think regarding this action being next to the comment. I think that since this action is not as frequently used as the reply to action, that it adds more noise than it is worth. Perhaps if it was only enabled upon selection in the viewer or only available as a contribution to the context menu (not currently feasible I believe)?
Created attachment 79787 [details] Patch with AbstractRepositoryConnector.getTaskUrl (In reply to comment #7) > You can get task url using AbstractRepositoryConnector.getTaskUrl(String > repositoryUrl, String taskId) there is no API for getting urls that include > comments and present hyperlink detectors can't handle url pointers to comments > (need a separate bug for that). Do you think that it is needed more than in this case. If so I think we can do it. > So, I think for now it is better to leave comment out of url and just say it in > text. That is what I did. > > BTW, it could be useful to be able to create issue only from selected text. And > this action should be also available from the popup menu. > > Also it seems like this issue represent use case for bug 203798. Another use > case is create template from selected comment text, see bug 201028. > (In reply to comment #8) > What do other's think regarding this action being next to the comment. I think > that since this action is not as frequently used as the reply to action, that > it adds more noise than it is worth. Perhaps if it was only enabled upon > selection in the viewer or only available as a contribution to the context menu > (not currently feasible I believe)? > For my it is OK to have it next to the reply because it use not much space. But I think the contribution to the context menu is a good secound way for this.
Created attachment 79788 [details] mylyn/context/zip
(In reply to comment #8) > only available as a contribution to the context menu (not currently feasible I believe)? it does make sense to have it only in the popup menu
(In reply to comment #11) > (In reply to comment #8) > > only available as a contribution to the context menu (not currently feasible I > believe)? > > it does make sense to have it only in the popup menu Why that? the following Actions are in popup menu and at the top of the window. - syncronize - Open with Web Browser - Deactivate Task only - Show History is not present. So why not have all the actions in two places?
(In reply to comment #12) > > it does make sense to have it only in the popup menu > Why that? Because, like Rob said, this action is not frequently used to justify for cluttering comment header, so in my opinion item in popup menu is most appropriate. It also don't make sense to have this action on main editor action bar (the one where we have history and open with browser), because it is specific to the selected comment, but other actions apply for the entire task editor. > the following Actions are in popup menu and at the top of the window. > - syncronize > - Open with Web Browser > - Deactivate Task > > only > - Show History > is not present. > > So why not have all the actions in two places? Yes, we need to add show history to the task editor popup menu and to the popup mnu in the task list.
+1 for restricting this action to the comment viewer's popup menu. It probably makes sense to put it with the other textual actions, since it operates on the selected text and not on the task itself.
(In reply to comment #13) > (In reply to comment #12) > > > it does make sense to have it only in the popup menu > > Why that? > > Because, like Rob said, this action is not frequently used to justify for > cluttering comment header, so in my opinion item in popup menu is most > appropriate. It also don't make sense to have this action on main editor action > bar (the one where we have history and open with browser), because it is Until now for me there was no need of action - Open with Web Browser - Deactivate Task - Show History so al at last for me there is no need to have this in main editor action bar. > specific to the selected comment, but other actions apply for the entire task > editor. > Sorry that was only an example tha oher actions are also not frequently used. I never want to have the new bug from comment in the main editor action bar. > > the following Actions are in popup menu and at the top of the window. > > - syncronize > > - Open with Web Browser > > - Deactivate Task > > > > only > > - Show History > > is not present. > > > > So why not have all the actions in two places? > > Yes, we need to add show history to the task editor popup menu and to the popup > mnu in the task list. >
(In reply to comment #15) > Until now for me there was no need of action > - Open with Web Browser > - Deactivate Task > - Show History > at last for me there is no need to have this in main editor action bar. I know that many people are using all above actions very often. It is not a big deal to add new action to the editor action bar, but this particular action is specific to the selected comment, so it don't really belong to the main bar, but we also don't want to add new button on every comment header. That is why popup menu is the best place for it. PS: by the way, can you please only quote as much as needed when replying to comments
(In reply to comment #8) > What do other's think regarding this action being next to the comment. I think > that since this action is not as frequently used as the reply to action, that it > adds more noise than it is worth. Perhaps if it was only enabled upon selection > in the viewer or only available as a contribution to the context menu (not > currently feasible I believe)? Is someone working on this? If the answer in no should I look at this? 1) is RepositoryTaskSelection the right place to start. Field taskComment is defined but if I see it right never used. 2) CopyTaskDetailsAction.getTextForTask use the RepositoryTaskSelection but I didn't find what to select to use this code.
Frank, I'm reassigning to you. 1) RepositoryTaskSelection should be getting the selected comment so would be a great place to start on this. 2) I'm not certain but the 'CreateTaskFromComment' action may have to be dynamically contributed to the popup similarly to those in TaskEditorActionContributor.
Created attachment 80500 [details] Patch with Action in popup menu and buttontoolbar Sorry RepositoryTaskSelection is not used because I was unable to figure out how to extend this. Please verify if my implementation is OK.
Created attachment 80501 [details] mylyn/context/zip
Created attachment 81215 [details] Revision Hi Frank. This is looking good. Here is a revision making use of RepositoryTaskSelection. You will notice the improvement I had to make to construction of RepositoryTaskSelection adding the comment to the selection. I notice that there is also aparameter we were using a while back for the currently selected text which is no longer being used. I think this is the perfect driver for using it again and setting it to the currently selected text from the comment. Then we can use this to create the new bug report with just the text which is selected (very handy in my opinion). Since you are passing the task data along, we could pass this along ot the new bug creation process somehow and let teh appropriate connector create the new report with the same fields (so that priority, severity etc are also cloned). Thoughts?
Created attachment 81216 [details] mylyn/context/zip
Created attachment 82013 [details] add use of selected commenttext (In reply to comment #21) > Then we can use this to create the new bug report with just > the text which is selected (very handy in my opinion). Included in this patch. > > Since you are passing the task data along, we could pass this along ot the new > bug creation process somehow and let teh appropriate connector create the new > report with the same fields (so that priority, severity etc are also cloned). > Thoughts? If we do this is it right that we need a map within AbstractRepositoryTaskEditor for get the TextField/CCombo of an attribute? What bugzilla attributes should we set? - all (Version, Component Platform OS, Priority Serverity and URL) or - only some. What is needed if we have an other RepositoryKind between new and source? - Try to map the attributes - set nothing
Created attachment 82014 [details] mylyn/context/zip
Thanks for the patch Frank. It would be great if you could make the implementation more generic so it could be reused for bug 161646 which overlaps significantly with this bug. Also related are bug 209215 and bug 207524 which require cloning of task data attributes as well. I have discussed possible approaches for that with Rob: * For cloning of task data a new method should be added to AbstractTaskDataHandler. A default implementation could clone the common attributes: summary, description and possibly iterate over editable attributes of the source task data and the new task data. The latter is probably only feasible if both task data objects are associated with the same repository. Connectors can overwrite that method and provide a more specific implementation if needed. * Creating new tasks is connector specific and handled in getNewTaskWizard(). The task data needs to be passed to the wizard and cloning needs to handled by the connector before the editor is opened. This requires new API (probably in AbstractRepositoryConnectorUi). The current approach of accessing the editor after it is opened by the wizard is too fragile. It could happen that the wrong editor is active and the comment is pasted into that editor instead. * NewTaskWizard is the default implementation of the new task wizard and should provide an implementation that calls AbstractTaskDataHandler to clones task data attributes before opening the editor. To make this reusable for the other bugs mentioned above the code should also be able to clone from AbstractTask objects when no task data is available or the connector does not support task data. This will require significant test coverage particularly when tasks are cloned accross repositories. It would be a good start to begin with adding the cloning API to AbstractTaskDataHandler and then implement the UI/wizard part.
(In reply to comment #25) > Thanks for the patch Frank. It would be great if you could make the > implementation more generic so it could be reused for bug 161646 which overlaps > significantly with this bug. Also related are bug 209215 and bug 207524 which > require cloning of task data attributes as well. > > I have discussed possible approaches for that with Rob: > OK I start working on this. Should we do the steps from your Comment in sub bugs? Like you did for bug 200634? > * For cloning of task data a new method should be added to > AbstractTaskDataHandler. A default implementation could clone the common > attributes: summary, description and possibly iterate over editable attributes > of the source task data and the new task data. The latter is probably only > feasible if both task data objects are associated with the same repository. > Connectors can overwrite that method and provide a more specific implementation > if needed. > > * Creating new tasks is connector specific and handled in getNewTaskWizard(). > The task data needs to be passed to the wizard and cloning needs to handled by > the connector before the editor is opened. This requires new API (probably in > AbstractRepositoryConnectorUi). The current approach of accessing the editor > after it is opened by the wizard is too fragile. It could happen that the wrong > editor is active and the comment is pasted into that editor instead. > > * NewTaskWizard is the default implementation of the new task wizard and should > provide an implementation that calls AbstractTaskDataHandler to clones task data > attributes before opening the editor. To make this reusable for the other bugs > mentioned above the code should also be able to clone from AbstractTask objects > when no task data is available or the connector does not support task data. > > This will require significant test coverage particularly when tasks are cloned > accross repositories. It would be a good start to begin with adding the cloning > API to AbstractTaskDataHandler and then implement the UI/wizard part.
Using a sub-task for adding the clone API seems like a good idea: bug 209402.
Please excuse the confusing back and forth on the subtasks for this bug. The required API should now be in place. Frank. would you be interested in refactoring your patch to make use of the new AP?. You can use NewTaskFromJunitResultViewAction as an example for creating tasks from a string.
(In reply to comment #28) > Frank. would you be interested in refactoring your patch to make use of the new > AP?. You can use NewTaskFromJunitResultViewAction as an example for creating > tasks from a string. OK I hope that I can do this over the weekend.
Created attachment 83199 [details] Patch with use of the new API
Created attachment 83200 [details] mylyn/context/zip
Steffen, passing to you for review since you've been working with this api...
Applied patch with minor modifications: - renamed NewBugFromCommentAction to NewTaskFromCommentAction (bug is the Bugzilla specific terminology) - renamed TaskFormPage.getSeletedTextFromActualEdit() to getSelectionText() - set the isDescription flag on RepositoryTaskSelection to maintain API semantics - renamed editor1 to formPage - added @since tags to new API - replaced !selectedCommentText.equals("") by selectedCommentText.length() > 0 - removed the action accelerator which did not work for me The action seems a bit out of place in the middle of the context menu. Frank, could you post a follow-up patch that moves the action into the New sub-menu? Another things that needs to be addressed is the case when taskData == null when the action is run. This will result in a NullPointerException. Could you please provide a test case that triggers this and a fix?
Any chance these actions can be done trough object contribution? So, they could work from the outline view too. See bug 203798
(In reply to comment #33) > Applied patch with minor modifications: > > - renamed NewBugFromCommentAction to NewTaskFromCommentAction (bug is the > Bugzilla specific terminology) > - renamed TaskFormPage.getSeletedTextFromActualEdit() to getSelectionText() > - set the isDescription flag on RepositoryTaskSelection to maintain API > semantics > - renamed editor1 to formPage > - added @since tags to new API > - replaced !selectedCommentText.equals("") by selectedCommentText.length() > 0 > - removed the action accelerator which did not work for me OK lessen learned! :-) > > The action seems a bit out of place in the middle of the context menu. Frank, > could you post a follow-up patch that moves the action into the New sub-menu? How can i do tis. For me the problem is that the New sub-menu is crate by ObjectContribution and I don't know how to ad an item to this submenu. If I use the objectContribution I hve the problem that I must get the selected TaskComment from the Editor. How can I get this? > Another things that needs to be addressed is the case when taskData == null when > the action is run. This will result in a NullPointerException. Could you please > provide a test case that triggers this and a fix? I will do this if I know that the previous question is answered.
(In reply to comment #35) > How can i do tis. For me the problem is that the New sub-menu is crate by > ObjectContribution and I don't know how to ad an item to this submenu. > If I use the objectContribution I hve the problem that I must get the selected > TaskComment from the Editor. How can I get this? It should work if you create a sub-menu with a matching id like this: MenuManager newMenuManager = new MenuManager("New", "org.eclipse.mylyn.tasks.ui.menu.new"); manager.add(newMenuManager); newMenuManager.add(newTaskFromCommentAction);
Created attachment 83394 [details] follow-up patch With the test I don't know if we should od more. If you think we should add an test like the followning 1) create an Task with at least one Comment 2) open the TaskEditor and select a Comment 3) Trigger the NewTaskFromCommentAcion 4) select an Repository / Produkt 5) test if the new Task is created correctly. then I need some help. What can used as an startingpoint. How do I userinteraction like select an Repository from an jUnit Test
Created attachment 83395 [details] mylyn/context/zip
Great stuff guys! I did a design review with Steffen, and here's are some pointers for improving the UI that should be straightforward changes for Steffen to implement: * Do not use a New submenu on the Task Editor. The Eclipse convention is that popup menus on editors do not have a New menu on them, instead the simple creation actions come from the toolbar or File menu. Thankfully we don't have to rely on the global toolbar, since the Task Editor's toolbar is a great place for the New Subtask action. * The New Task from Comment action is an action that operates on text in order to create a task. As such, I think that it should be more generic, and work for any text selection in the task editor (e.g. Notes under planning, New Comment), and that there are significant use cases for supporting this (e.g. I just wrote a long comment and now realize it should be a new bug). As such, I propose generalizing the action to be New Task from Selection and putting it in the same section as the other text selection actions (e.g. just under Select All). When the selection is a comment you should still keep your very nice functionality of ensuring that the text links to the comment. Since the action name is generic and clear enough, the action can be as smart as it wants about the current selection, so you can keep your handling of no text selection in a comment exactly the way it is now.
Thanks for the patch Frank! I have integrated your changes and refactored the code to work on text selections as well as on comments. The class is now called NewTaskFromSelection. Please review my changes and comment here if there additional functionality should be added. You can take a look at NewTaskFromSelectionActionTest if you would like to contribute additional test cases. I am not sure if it is worth the effort to create test cases that operate on an actual editor. These type of UI tests tend to get very complicated and are fragile when the editor layout etc. changes. The API refactorings related to subtasks are tracked on bug 210590. The menu has been restructured as per Mik's comment.
Good job! A few suggestions: - When you right-click a comment, it is strange to have the action called "New Task from Selection", since nothing is selected. - The new task starts with a comment like: "URL: https://bugs.eclipse.org/bugs/show_bug.cgi?id=xxxx Comment: 1" Instead, it should be better to use the comment URL, like (in bugzilla): "URL: https://bugs.eclipse.org/bugs/show_bug.cgi?id=xxxx#c1" - "Created from Comment" sounds a little strange for me. Wouldn't be better "Created from Task" or "Create from Task Comment"?
Thanks for the feedback Willian. > - When you right-click a comment, it is strange to have the action called "New > Task from Selection", since nothing is selected. I agree. We could dynamically rename the action to "New Task from Comment" in that case but that could be even more confusing. Mik, is there an Eclipse guideline that covers this? > - The new task starts with a comment like: > > "URL: https://bugs.eclipse.org/bugs/show_bug.cgi?id=xxxx > Comment: 1" > > Instead, it should be better to use the comment URL, like (in bugzilla): > > "URL: https://bugs.eclipse.org/bugs/show_bug.cgi?id=xxxx#c1" Yes, unfortunately we are currently lacking support in the API to determine the URL of a comment: 210317: [api] add method to determine URL for comment https://bugs.eclipse.org/bugs/show_bug.cgi?id=210317 > - "Created from Comment" sounds a little strange for me. Wouldn't be better > "Created from Task" or "Create from Task Comment"? I am fine with either suggestion. Other opinions on this?
(In reply to comment #42) > Thanks for the feedback Willian. > > > - When you right-click a comment, it is strange to have the action called "New > > Task from Selection", since nothing is selected. > > I agree. We could dynamically rename the action to "New Task from Comment" in > that case but that could be even more confusing. Mik, is there an Eclipse > guideline that covers this? The thing that's most in keeping with the guidelines is to have comments be selectable, since we are treating them as an object in the UI. So when you right-click a comment, it's title bar becomes highlighted, it gets linked in the Outline, etc. That can preserve the generic naming of the action, so I think we need a new bug for this ability to make comments properly selectable. > > - "Created from Comment" sounds a little strange for me. Wouldn't be better > > "Created from Task" or "Create from Task Comment"? > > I am fine with either suggestion. Other opinions on this? -- From Comment: https://bugs.eclipse.org/bugs/show_bug.cgi?id=169426#42
(In reply to comment #43) > The thing that's most in keeping with the guidelines is to have comments be > selectable, since we are treating them as an object in the UI. So when you > right-click a comment, it's title bar becomes highlighted, it gets linked in > the Outline, etc. That can preserve the generic naming of the action, so I > think we need a new bug for this ability to make comments properly selectable. What about creating a button right after the "reply" button? This would help the user to discover this feature, although I'm afraid it would make the comment bar looks bloated after some time, since this feature would not be very used on daily basis.
(In reply to comment #44) > What about creating a button right after the "reply" button? Please see comment #8 and following.
Reassigning.
Resolving.
FYI, there is a little glitch when creating from long line selections. I create bug#210843 for that.
