Community
Participate
Working Groups
Currently we get the following error, may want to handle this specific case and say it needs to be done with the Web UI until uspported org.eclipse.mylar.internal.tasks.core.UnrecognizedReponseException: <!DOCTYPE "http://www.w3.org/tr/html4/loose.dtd"="" transitional//en"="" public="" "-//w3c//dtd="" 4.01="" html=""> <html> <head> <title>Verify New Product Details...</title> <link href="https://bugs.eclipse.org/bugs/" rel="Top"> ...
We have all the information needed to move bugs across components, and to support creation of bugs without forcing the user to select a component in the wizard (bug 244553). It is also the biggest chunk of Bugzilla functionality missing from the rich editor.
(In reply to comment #1) > We have all the information needed to move bugs across components for components within the same product this already implemented or did you mean something different? >, and to > support creation of bugs without forcing the user to select a component in the > wizard (bug 244553). Should this mean that we define an default Product/Component and let the user change that Product/Component after creation? > It is also the biggest chunk of Bugzilla functionality > missing from the rich editor. Please give me some more information and I look what can be done here.
(In reply to comment #2) > for components within the same product this already implemented or did you mean > something different? Sorry, I meant products! I updated the summary accordingly. > Should this mean that we define an default Product/Component and let the user > change that Product/Component after creation? I figure that the simplest way to make this happen is the following, since it avoids forcing the user to have to deal with an extra wizard page/dialog, which is effectively what the Bugzilla Web UI does. 1) User changes the Product attribute, causing the task editor to make the values of the attributes that no longer match be blank (Component and Target milestone). 2) User cannot submit the task editor until those values are selected, similar to how they currently cannot submit a new task editor without selecting the product. How does that sound?
(In reply to comment #3) > (In reply to comment #2) > > for components within the same product this already implemented or did you > mean > > something different? > > Sorry, I meant products! I updated the summary accordingly. > > > Should this mean that we define an default Product/Component and let the user > > change that Product/Component after creation? > > I figure that the simplest way to make this happen is the following, since it > avoids forcing the user to have to deal with an extra wizard page/dialog, which > is effectively what the Bugzilla Web UI does. > 1) User changes the Product attribute, causing the task editor to make the > values of the attributes that no longer match be blank (Component and Target > milestone). > 2) User cannot submit the task editor until those values are selected, similar > to how they currently cannot submit a new task editor without selecting the > product. > > How does that sound? OK, now I think I can create a patch for this. Is this OK that I start this after 3.0.2 is released?
Excellent. Yes, post 3.0.2 is good timing for this, since it's too big a change for 3.0.2.
Created attachment 112518 [details] first part of patch included is the new Editor for Bugzilla Products that has support for update of the Component and the Target Milestone attributes. I need some help for the implementation of the UI part. What is the way to get the editor of an other attribute (Component or Target Milestone) from Product Editor
Created attachment 112519 [details] mylyn/context/zip
Rob: Please reivew.
Hello, since we are about to migrate from our self made bug tracker accessed by the Generic Web Connector to a Trac system, I wonder how far this bug has been progressed. Will it be possible to move bugs from the Generic Web connector to Trac using Mylyn? This would be really great stuff! Looking forward to see this in one of the next weekly builds? Thanks, Jörg
This bug is specific to the Bugzilla connector for moving bugs across products within a sinlge Bugzilla repository. Mylyn currently does not have built-in functionality for migrating bugs between repositories but this could be implemented based on the tasks core API. Joerg, please file a separate bug for that detailing your use case.
(In reply to comment #10) > This bug is specific to the Bugzilla connector for moving bugs across products > within a sinlge Bugzilla repository. > > Mylyn currently does not have built-in functionality for migrating bugs between > repositories but this could be implemented based on the tasks core API. Joerg, > please file a separate bug for that detailing your use case. Done, see: 249434: [discussion] Copy tasks to different connector https://bugs.eclipse.org/bugs/show_bug.cgi?id=249434
*** Bug 175324 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > Created an attachment (id=112518) > first part of patch > > included is the new Editor for Bugzilla Products that has support for update of > the Component and the Target Milestone attributes. > > I need some help for the implementation of the UI part. > > What is the way to get the editor of an other attribute (Component or Target > Milestone) from Product Editor Implementing a map from attribute -> editor part is being considered for 3.1 (bug#248369).
Given the current plan providing a mapping between data model and UI elements is probably not going to make it into 3.2. Here is how I could see this getting implemented for Bugzilla in time for 3.1: Track the mapping between task attributes and attribute editors in the factory created by BugzillaTaskEditorPage.createAttributeEditorFactory(). Register a listener using BugzillaTaskEditorPage.getModel().addModelListener() that gets notified when a product is selected. Update other attributes (component, versions, milestone) accordingly and refresh the UI. This would require AbstractTaskEditorPart to implement refresh() and a similar method on AbstractAttributeEditor. Frank, as a first cut we could implement the Bugzilla portion and the UI refresh for TaskEditorAttributePart and SingleSelectionAttributeEditor. That should be sufficient to resolve this bug and we can then consider applying the same change to other attribute editors and moving more of the functionality into the framework. Would you be interested in taking a pass at this?
(In reply to comment #14) > Given the current plan providing a mapping between data model and UI elements is > probably not going to make it into 3.2. Here is how I could see this getting > implemented for Bugzilla in time for 3.1: > > Track the mapping between task attributes and attribute editors in the factory > created by BugzillaTaskEditorPage.createAttributeEditorFactory(). > > Register a listener using BugzillaTaskEditorPage.getModel().addModelListener() > that gets notified when a product is selected. Update other attributes > (component, versions, milestone) accordingly and refresh the UI. This would > require AbstractTaskEditorPart to implement refresh() and a similar method on > AbstractAttributeEditor. > > Frank, as a first cut we could implement the Bugzilla portion and the UI refresh > for TaskEditorAttributePart and SingleSelectionAttributeEditor. That should be > sufficient to resolve this bug and we can then consider applying the same change > to other attribute editors and moving more of the functionality into the > framework. Would you be interested in taking a pass at this? OK, I start with this now.
Created attachment 121030 [details] first cut patch see comment#14
Created attachment 121031 [details] mylyn/context/zip
The patch looks very good! I'll take a second pass at it and will go over it with Rob, so we get this into 3.1.
Created attachment 121482 [details] first cut patch with fix for bug#219911 Sorry I forgot to include the patch for bug #219911 in the last patch.
Created attachment 121483 [details] mylyn/context/zip
Created attachment 121492 [details] updated patch
Created attachment 121493 [details] mylyn/context/zip
Rob, please review the patch.
The main changes in the updated patch is that I moved some of the implementation from AbstractTaskEditorPage to BugzillaTaskEditorPage. We can consider moving that back once the API is stabilized. I also refactored some of the code in the attribute editors to avoid code duplication.
Frank, if I test this patch with the Mylyn Bugzilla 2.22 repository I still get an error message that asks me to "Verify New Product Details...". Have you been able to move bugs between products without getting this error?
(In reply to comment #25) > Frank, if I test this patch with the Mylyn Bugzilla 2.22 repository I still get > an error message that asks me to "Verify New Product Details...". Have you been > able to move bugs between products without getting this error? Yes I get this error to. Until bug# 259670 is fixed wo need to set the "Reassign to default assignee" within the attribute section by hand.
Frank, I'll be applying your current patch but to the new task editor only to implement bug#244553. Would you be willing to investigate a workaround to the problem of Bugzilla always asking to verify the details upon moving an *existing* bug to another product. For example, if upon posting the task data we get back the verify page, we could immediately post (all from within the client) the information we already have from the task data. Also, if you could file a bug against bugzilla.org requesting that if valid data is passed (i.e. for version) when moving products that they simply return the standard 'Changes submitted' page.
Created attachment 122759 [details] patch for comment#27 To not show the verification page I add the Attribute "confirm_product_change" which was included in the verification html
Created attachment 122761 [details] mylyn/context/zip
(In reply to comment #28) > Created an attachment (id=122759) > patch for comment#27 > > To not show the verification page I add the Attribute "confirm_product_change" > which was included in the verification html This is great news Frank! I'll take a look...
Frank, this works great on Bugzilla 3.2. Is there a similar attribute to make the older 2.22 and 2.18 repos work as well?
(In reply to comment #31) > Frank, this works great on Bugzilla 3.2. Is there a similar attribute to make > the older 2.22 and 2.18 repos work as well? > My oldest version is 3.0.4 and there this field is also included. (<input type="hidden" name="confirm_product_change" value="1">) If it is possible to an an other product to the mylyn.eclipse.org/bugs??? repositories I can try if this is present.
You can have a look at http://mylyn.eclipse.org/bugs222/show_bug.cgi?id=80
(In reply to comment #33) > You can have a look at http://mylyn.eclipse.org/bugs222/show_bug.cgi?id=80 > OK, I found that this field confirm_product_change was not in bugs222 but in 3.0. So we need to restrict the product change to work for >= 3.0 or find a way for the older version. What do you think?
(In reply to comment #34) > (In reply to comment #33) > > You can have a look at http://mylyn.eclipse.org/bugs222/show_bug.cgi?id=80 > > > > OK, I found that this field confirm_product_change was not in bugs222 but in > 3.0. So we need to restrict the product change to work for >= 3.0 or find a way > for the older version. What do you think? Agreed. We'll need to just allow this functionality on existing bugs for >= 3.0 but can enable for all new bugs.
I wait until we have the patch for bug#260963 until I add a new call to getInstallVersion
Created attachment 125946 [details] final patch (In reply to comment #36) > I wait until we have the patch for bug#260963 until I add a new call to > getInstallVersion >
Created attachment 125947 [details] mylyn/context/zip
Created attachment 125965 [details] revision Works great! Minor updates: * added refresh of target milestone field * removed a method in BugzillaTaskEditorPage and reduced visibility of others Frank if you could do a sanity check on these changes that would be great. You may be able to eliminate some duplicate code in the ProductSelectionListener? Steffen, do you want to take a quick look at where this patch touches the attribute editors?
Created attachment 126067 [details] updated revision (In reply to comment #39) > Created an attachment (id=125965) > revision > > Works great! Minor updates: > > * added refresh of target milestone field Did you mean version field? > * removed a method in BugzillaTaskEditorPage and reduced visibility of others > > Frank if you could do a sanity check on these changes that would be great. You > may be able to eliminate some duplicate code in the ProductSelectionListener? > I only remove commeted code (BugzillaTaskEditorPage.refresh) > Steffen, do you want to take a quick look at where this patch touches the > attribute editors?
Created attachment 126068 [details] mylyn/context/zip
> Steffen, do you want to take a quick look at where this patch touches the > attribute editors? Looks good.
Great. Frank if you want to commit this, I'll merge with my changes for the new task toolbar menu.
(In reply to comment #43) > Great. Frank if you want to commit this, I'll merge with my changes for the new > task toolbar menu. Patch commited.
Great stuff Frank!
Marking resolved.
*** Bug 202311 has been marked as a duplicate of this bug. ***
