Bugzilla – Full Text Bug Listing
| Summary: | Support Bugzilla 3.0 custom resolutions | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Andrew Overholt <overholt> | ||||||||||||||||||||
| Component: | Mylyn | Assignee: | Frank Becker <eclipse> | ||||||||||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||||||||||||
| Severity: | enhancement | ||||||||||||||||||||||
| Priority: | P2 | CC: | eclipse, klee, mcepl, robert.elves, thofoer, wmitsuda | ||||||||||||||||||||
| Version: | unspecified | Keywords: | helpwanted | ||||||||||||||||||||
| Target Milestone: | 2.1 | ||||||||||||||||||||||
| Hardware: | All | ||||||||||||||||||||||
| OS: | All | ||||||||||||||||||||||
| Whiteboard: | |||||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||
|
Description
Andrew Overholt
Marking helpwanted for now. Rob: when you get a chance please comment on what adding this support would involve. I would like to help out on this bug, if this isn't too serious or time-critical because this would be my frist time working on Mylar. Excellent. We usually have a very fast turn-around with patches, especially when they come with test cases and task contexts. For guidelines on patches refer to: http://wiki.eclipse.org/index.php/Mylar_Contributor_Reference#Contributing_patches For getting your workspace set up for contributing see: http://wiki.eclipse.org/index.php/Mylar_Contributor_Reference#Workspace_setup Note that custom resolutions will be officially supported on Bugzilla 3.0: http://wiki.mozilla.org/Bugzilla:Roadmap https://bugzilla.mozilla.org/show_bug.cgi?id=94534 However custom status won't... Without too much investigation into this I believe that we'll need bugzilla support (3.0) for this (since I believe it will reject an unknown resolution). Kyu: with Red Hat do you have custom resolutions working on an earlier and unmodified Bugzilla? Or have you modified Bugzilla? If so and the modifications are substantial we could discuss whether or not it makes sense to have a separate Red Hat Bugzilla Connector that extends the Bugzilla Connector. But hopefully we can do this in a generic way. (In reply to comment #6) > Kyu: with Red Hat do you have custom resolutions working on an earlier and > unmodified Bugzilla? Or have you modified Bugzilla? I've asked Dave Lawrence <dkl@redhat.com> (who works on our bugzilla) and got, We are not currently using any kind of custom resolution code in our instance of Bugzilla. We are basically storing the possible list of resolutions in a flat table in the database, and then adding them to the drop down select on the Close bug line using a for loop in the template. We have always had our statuses and resolutions uppercase instead of lowercase such as RAWHIDE or MODIFIED. What is needed by the Mylar project to be able to work with our list of resolutions they(the) way they are currently? > If so and the > modifications are substantial we could discuss whether or not it makes sense to > have a separate Red Hat Bugzilla Connector that extends the Bugzilla Connector. > But hopefully we can do this in a generic way. > I guess it'll depend on how bugzilla 3.0 implements custom resolutions. If it's compatible with how Red Hat Bugzilla does, we'll just need a generic connector. *** Bug 178611 has been marked as a duplicate of this bug. *** Bugzilla 3.0 has ability to add custom resolution fields. http://www.bugzilla.org/releases/3.0/new-features.html#v30_feat_cr Postponing to 3.0 cycle. Rob: how hard is this? Currently these values are hard coded in the connector. We just need to retrieve them from the configuration and use them instead. Shouldn't be too involved. Eclipse.org just added a new resolution NOT_ECLIPSE that we can't support without this feature. Raising priority. (In reply to comment #2) > I would like to help out on this bug, if this isn't too serious or time-critical > because this would be my frist time working on Mylar. (In reply to comment #13) > Eclipse.org just added a new resolution NOT_ECLIPSE that we can't support > without this feature. Raising priority. Is there any work on this? If no, should I take a look at this? (In reply to comment #12) > Currently these values are hard coded in the connector. We just need to retrieve > them from the configuration and use them instead. Shouldn't be too involved. Could you give me a reference to the Point in the source code ? Created attachment 76709 [details]
Patch
Please give this a look.
I think this can be used.
Created attachment 76710 [details]
mylyn/context/zip
Created attachment 76715 [details]
Custom Resolution
Frank, I have some code for this which I'm attaching for you here. It needs some improvements such as ignoring DUPLICATE resolution etc (that you have in yours). Note that your patch is using a method in BugzillaCorePlugin marked (albeit via javadoc) as 'public for testing'. Use of such methods is discouraged. I'll reassign to you. When you have a finished patch, prepend [patch] to the title of this bug report so it gets our attention.
Created attachment 76716 [details]
mylyn/context/zip
Created attachment 76736 [details]
corrected patch
Here the new version.
But what is with resolution REMIND and LATER. They are no longer defined if you set up a Bugzilla 3.0 repository. Should we remove them from the enum because the enum is only used when no config is found?
(In reply to comment #19) > But what is with resolution REMIND and LATER. They are no longer defined if you > set up a Bugzilla 3.0 repository. Should we remove them from the enum because > the enum is only used when no config is found? Perhaps we should do another version comparison there and have two different enums, one pre 3.0 and one post each with the out-of-the box resolutions (i.e. BUGZILLA_RESOLUTION_2.0 and BUGZILLA_RESOLUTION_3.0)? (In reply to comment #20) > (In reply to comment #19) > > But what is with resolution REMIND and LATER. They are no longer defined if > you > > set up a Bugzilla 3.0 repository. Should we remove them from the enum because > > the enum is only used when no config is found? > Perhaps we should do another version comparison there and have two different > enums, one pre 3.0 and one post each with the out-of-the box resolutions (i.e. > BUGZILLA_RESOLUTION_2.0 and BUGZILLA_RESOLUTION_3.0)? OK but keep in mind that we now use the enum only if we can't get the RepositoryConfiguration. But in this case repository.getVersion() can't be used to switch between BUGZILLA_RESOLUTION_2.0 and BUGZILLA_RESOLUTION_3.0. How can we get the Bugzilla Version? Currently I am at work, so I can't look in the source code! (In reply to comment #21) Sorry Frank, just realized that instead of getting the version from the configuration as we've done here and in your last patch we should be retrieving it directly from TaskRepository.getVersion(). This will solve the problem you indicate in comment#21 and will resolve the potential blocking issues in the other location. Created attachment 76809 [details] Patch with corrections from comment #22 The comments from #22 are integreted. BWT if GetVersion() retruns "Automatic (Use Validate Settings)" we have an problem during Validate Settings or an unsupportet Version like actually 3.1. Created attachment 76810 [details]
mylyn/context/zip
Also see bug 159397 and bug 196056 . We should ask the bugzilla people to allow finer grained querying of legal values for various options. This will prevent the retrieval of the full configuration for every minor detail we want to know in different places. How can we do this? Created attachment 76819 [details] new patch for comment#22 sorry wrong code included Created attachment 76820 [details]
mylyn/context/zip
Great. Patch applied, ip log updated. Frank, could you create a new bug report to address the issues stemming from "Automatic" being left as the version. It should probably never left but rather the latest release version should be selected by default (3.0). (In reply to comment #25) > Also see bug 159397 and bug 196056 . We should ask the bugzilla people to allow > finer grained querying of legal values for various options. > This will prevent the retrieval of the full configuration for every minor detail > we want to know in different places. How can we do this? The new web services api for bugzilla may support this. If not, we could request this support once we have the requirements (and start consuming this service). |