Community
Participate
Working Groups
I need to go to the browser view to do a 'clone this bug' command. I use this command in the situation where I have one application deployed on different sites. Each site is a bugzilla product, so once I determine that a bug has occurences on different sites, I want to report that. I can then resolve (=deploy), verify (=see in production) and close for each site separately. Can Mylar provide a Clone this Bug button on the form tab, or even as a popup menu item in the Task List?
committers, I was thinking of working on this. here are my thoughts: semantics * only tasks can be cloned at this point, simple task and repository tasks (we'll worry about the complications of cloning other things later if people request that feature explicitly) * only one task can be cloned at a time (i suppose people could want to clone multiple issues simultaneously, but it's much more straightforward to do it this way * clone ~= opening a new issue of the same type and intelligently filled in up with reasonable defaults from the selected issue (see questions below) ui * In the task list, have a rlight-click context menu option - "Clone" - just below rename above the separator bar * if multiple issues are selected, it will fail with an informative error msg dialog explaining only one can be selected * if a non-task item is selected, it will fail with an informative error msg dialog explaining that only simple or repository tasks can be cloned questions: 1) should the new issue have an automatic link to the issue it was cloned from? 2) should the new issue have an empty list of comments? (i'm thinking that linking the issues and leaving the description empty would be best because the most common use case for clone I can think of is when creating a single issue across various branches of development for a particular project, which to me means the comments would be divergent, just as the code bases are) 3) if you're cloning an issue that you didn't report, should the cloned issue keep the original reporter or be the current user? Is there anything else anyone wants to see this fix contain?
I requested a button on the form page to implement the functionality in the browser. But... the wider issue is bugtracking across multiple (n >= 2) code streams: see http://ask.slashdot.org/article.pl?sid=05/10/06/2248259 something which bugzilla offers only one solution for. So maybe it should not be 'Clone this bug' (n += 1), but 'Cascade this bug' (1 += n), where you can copy the description to a range of products in one go: think of the list that pops up when doing a create new repository task. 1) Yes, the new issue should have a track back to the original, htough I'm not sure that this should be a 'dependency' (as in bugzilla with bug#, can only point back to the same bugzilla instance), but more of a 'related to" with a URL ref to the original issue. THis would allow cloning/cascading over mutiple repositories. 2) Empty comment list, it's a new issue. Cloning/cascading is just an convenience method. 3) Current user should be the reporter of the cloned issue, with maybe putting the original reporter on the cc list. Next feature request would be to have a nice graphviz like View showing the graph or tree of related bugs color coded for resolution/status/priority ;-)
My suggested solution for this issue was trying to keep things as simple as possible, while still hitting most of the common use cases. The original description does mention, "or even as a popup menu item in the Task List", so that's what I went with. However, I suppose this functionality could *also* be exposed as a clone button on an opened task. 1) It wasn't my intention to make this a generic, cross-type clone operation. It meant meant to clone bugzilla issues -> bugzilla issues, jira issues -> jira issues, etc. If this is a needed feature, can we get some other comments on it? 2) OK, good, we're in agreement. 3) Sounds like a good suggestion to me.
Joseph, I believe the original intend of this bug was to support the native "clone" from bugzilla. You came out with a more generic, repository-aware, multi-repository, very powerful solution, which is very good :) I never had thought about this before, and sounds like a excellent idea.
This sounds great so far. Regarding the ui, if we go with adding clone to the popup we can just disable the action in the case of multiple selections / invalid tasklistelement selections.
Thanks guys. I appreciate the feedback. ; ) I think it's important to try and add value above and beyond what the underlying repos already provide - it gives people a greater incentive to use Mylar instead of more familar interfaces. Generally, I'd love to see Mylar completely blur the lines between what the different repositories provide. Towards that end, my aim is consistency, and thus why I wanted to implement it as a generic layer for all types of tasks.
This sounds excellent Maarten, and my thoughts are in line with the discussion above and I like the spec in comment#1. Doing the simplest thing to get this working first is actually the generic thing, so here are some concrete steps for how I suggest proceeding, and then we can build this out from there: 1) Add clone action to Task List popup menu, this will grab the ITask object selected 2) Make the action reuse the MultiRepositoryAwareWizard for selecting the repository 3) After the repository is selected, if the repository has a new task editor (AbstractRepositoryConnector.canCreate..(..)) open that new editor and fill in all generic fields that you can 4) Provide an URL-based link back to the originating bug in the description, probably right at the top. After this generic support is there, we will be able to delegate to connectors for duplicating connector-specific common fields. This won't support turning repository tasks into local until bug 124321 is resolved. Also, this solution could remove the need for bug 152211. Also note that this functionality is similar to NewTaskFromErrorAction, since it also pre-populates the content of the task. The attached context has the elements mentioned here as landmarks.
Mik, thanks for the pointers. I'll keep it in mind, and get on this tonight.
Since there have been no feedback reassigning to default.
(In reply to comment #7) Hi Mik, this has been open for too long so I decided to help out here. > 1) Add clone action to Task List popup menu, this will grab the ITask object > selected See attachment image, I have used CMD-D for duplicate. Need to do a proper icon still. > 2) Make the action reuse the MultiRepositoryAwareWizard for selecting the > repository Done, can create a new repository task > 3) After the repository is selected, if the repository has a new task editor > (AbstractRepositoryConnector.canCreate..(..)) open that new editor and fill in > all generic fields that you can Only two text fields are easily settable, the rest are menu's > 4) Provide an URL-based link back to the originating bug in the description, > probably right at the top. This works. > After this generic support is there, we will be able to delegate to connectors > for duplicating connector-specific common fields. I think we must add an single overrideable copyFrom(AbstractTask task) method where an editor can set all fields from the originating task, which then chains back up using super(); I'm a bit stuck now for what is in AbstractTask and what in the bugzilla one
Created attachment 78540 [details] Patch in reply to comment 7 Still need to work out how to set all the other fields from the originating task.
Created attachment 78541 [details] mylyn/context/zip
Created attachment 78542 [details] Screen shot of menu position and text
Excellent! The patch contains the comment text, could you please cut it again?
Created attachment 78610 [details] Bug 161646 - v1 - second upload Adding clone this bug in the way Mik described
Created attachment 78611 [details] mylyn/context/zip
I was planning on putting the copying in AbstractRepositoryTaskEditor method thus: /** * Fill the new task editor from an existing task. Implement in subclasses to * copy more fields when from the same or a 'friend' repository kind. * * @param task the task to copy fields from */ public void fillFromTask(AbstractTask task) { // ignore this.setSummaryText(task.getSummary() + " (cloned)"); this.setDescriptionText("Clone of bug#" + CopyTaskDetailsAction.getTextForTask(task)); // TODO set other standard repository fields here, like: // priority, severity, resolution, status, reporter , etc // TODO override this in the subclasses to set extra fields! } Then this can be overridden in subclasses. But I also found AbstractNewRepositoryTaskEditor. What is the difference and is that a better place?
The following worked... 5663: LoadTest (cloned) https://landfill.bugzilla.org/bugzilla-tip/show_bug.cgi?id=5663
Patch applied. Great stuff Maarten! Please review my changes, in particular noting the following: * Renamed action to CloneTaskAction * Suppress showing it for local tasks because the interaction was a bit weird, but we consider adding * Changed to use BaseSelectionListenerAction * Changed to use target task's prefix (e.g. "issue" for JIRA vs. "bug" for Bugzilla) Could you also provide a unit test that invokes this action on a MockRepositoryTask or a BugzillaTask and verifies that the summary was set properly on the new task? Shawn: this is very closely related to your efforts on bug 203471, so you may want to look over this and comment.
Created attachment 78803 [details] mylyn/context/zip
(In reply to comment #19) > * Renamed action to CloneTaskAction also renamed instance variable > * Suppress showing it for local tasks because the interaction was a bit weird, > but we consider adding > * Changed to use BaseSelectionListenerAction > * Changed to use target task's prefix (e.g. "issue" for JIRA vs. "bug" for > Bugzilla) Use AbstractNewRepositoryTaskEditor. instead of AbstractRepositoryTaskEditor. Moved all of that into a new method in AbstractNewRepositoryTaskEditor. Added a stub method in the bugzilla implementation (still need to find out how it stores it attributes) > > Could you also provide a unit test that invokes this action on a > MockRepositoryTask or a BugzillaTask and verifies that the summary was set > properly on the new task? will do > Shawn: this is very closely related to your efforts on bug 203471, so you may > want to look over this and comment.
Created attachment 78822 [details] Final edits Moved cloning/setting to overridable method AbstractNewRepositoryTaskEditor Renamed instance variable Added stub in bugzilla implementation
Created attachment 78823 [details] mylyn/context/zip
(In reply to comment #19) > Could you also provide a unit test that invokes this action on a > MockRepositoryTask or a BugzillaTask and verifies that the summary was set > properly on the new task? All existing unit tests for actions only test the static methods in those Actions. As I have put the copy in a overridable method in the editor, I can;' test, as there is no MockEditor :-( Please provide some tips on how to do this!
Mik, Rob, this is a bugday bug that need followup. Can you please advise on testing issues and review attached patch. It also seems like patch went stale and need to be recreated, which is unfortunate.
Eugene: the patch was applied and was included in 2.1. Maarten: a good way to test this would be to tell a new MockRepositoryTask to duplicate itself, then inspect the workbench to see what editors are open, find the new editor, and check that its Description was populated correctly. It may be more straightforward for you to just create a MockTaskEditor as you imply. Let me know if you would like additional pointers to similar test code. Also see: http://wiki.eclipse.org/index.php/Mylyn_Contributor_Reference#Writing_Tests
(In reply to comment #26) > Maarten: a good way to test this would be to tell a new MockRepositoryTask to > duplicate itself, then inspect the workbench to see what editors are open, find > the new editor, and check that its Description was populated correctly. It may > be more straightforward for you to just create a MockTaskEditor as you imply. > Let me know if you would like additional pointers to similar test code. Also > see: http://wiki.eclipse.org/index.php/Mylyn_Contributor_Reference#Writing_Tests I've tried to follow your tips. I create a new MockRepository and the copy one task. To do this, I've refactored the run() method. run() now gets the selection form the TaskManager and calls a new static method cloneTask(AbstractTask task) that will do the repository selection and cloning. I can thus call cloneTask(task) with a task from the MockRepository in my unit test. However the new task editor can not be retrieved in this part as apparently UI threads are blocked during the unit test. So the new task editor only comes up once the unit test has failed :-( This can occur in real life as well so I have added a waitUI() method like delay() in chapter 2.8 Writing Plug-in Tests in "Building Commercial Quality Plug-ins" Next problem is that I feel that the Editor should derive from AbstractNewRepositoryTaskEditor, not AbstractRepositoryTaskEditor like in your code. After all this is an editor for a task created but not yet present in a repository. Then the actual copying of fields can be delegated to a method in every subclass of AbstractNewRepositoryTaskEditor, like BugzillaNewRepositoryTaskEditor. This is the method to override to copy more fields than the two done now. Alas MockRepository returns a TaskEditor which is not a subsclass of AbstractNewRepositoryTaskEditor :-(
Created attachment 79469 [details] Changed CloneTaskAction, delegated cloning, initial unit test I've split the cloneTaskAction so it can be called easier from a unit test. The MockRepository does not subclass AbstractNewRepositoryTaskEditor so fails and produces some text to copy paste. The copying should be in the editor or subclass, as that allows the copying of more field sfor a known original Task type.
Created attachment 79470 [details] mylyn/context/zip
Rob: please review.
We're holding off on this until we can make use of the api that emerges from bug#209402.
The API that let's connectors initialize the new task editor from existing tasks has been merged. Maarten, please take a look at the changes that were made to CloneTaskAction and AbstractTaskDataHandler.cloneTaskData(). Please comment if the implementation is not sufficient to support cloning of tasks. I'll look into improving support for JIRA and Bugzilla which still clone the old way that only sets summary and description but does not copy other attributes.
(In reply to comment #32) > .... Please comment if > the implementation is not sufficient to support cloning of tasks. In my old implementation I also put a '(Cloned)' suffix after the summary, but that is cosmetic. I still wonder how we're going to handle moving a bug from say bugzilla to JIRA. use the adapter mechanism and create some sort of generic task? I'm happy for now and see the value of creating api. Now you can clone a bug, create a bug from a comment, create a sub-task, all the time back linking to the originator.
(In reply to comment #33) > I still wonder how we're going to handle moving a bug from say bugzilla to JIRA. > use the adapter mechanism and create some sort of generic task? Yes, implementing mapping support for converting between different task models or to a more extensive generic format is certainly on the table for 3.0.
