Community
Participate
Working Groups
Although we may not be able to support this feature we need to ensure that submitting bugs with set flags does not drop the flags from the report.
I think these are now enabled on bugs.eclipse.org because I've seen them used for voting on LATER/REMIND states.
Committing doesn't delete existing flags.
Is there any plan to add support for bugzilla review flag?
Unfortunately Bugzilla doesn't expose enough of the necessary information to implement this feature well within the task editor. Next action should be to document the information we need and submit a bug report to bugzilla.org.
Frank, low priority in terms of 3.0 but at some point if you have a moment, perhaps you could investigate this and throw up a summary of what is missing an recommended course of action.
(In reply to comment #5) > Frank, low priority in terms of 3.0 but at some point if you have a moment, > perhaps you could investigate this and throw up a summary of what is missing an > recommended course of action. Here what i figured out until now. * Flags are only included in the /show_bug.cgi?id=nnn&ctype=xml if the status is set. * /config.cgi?ctype=rdf did not include any information about defined flags. Bug https://bugzilla.mozilla.org/show_bug.cgi?id=431363 created.
Great, I've voted on https://bugzilla.mozilla.org/show_bug.cgi?id=431363, if others could that would help.
Created attachment 99544 [details] patch This is only the first part. Only the background changes are included. For the UI I wait until the refectoring is done.
Created attachment 99548 [details] patch This is only the first part. Only the background changes are included. For the UI I wait until the refectoring is done.
Created attachment 99549 [details] mylyn/context/zip
Patch applied, ip log updated. Once I get the editor refactored we can work up the ui for this... great stuff.
Created attachment 106667 [details] updateted Patch Here a Patch with a Editor for Flags. Next Steps: 1) Add configuration support for Fflags per component 2) Add support for flagtype requestable (specifically) multiplicable (extra flag addl. from html) 3) add support for not used flags (flags with state = "") Please check if this patch is the right way to implement this.
Created attachment 106668 [details] mylyn/context/zip
Hi Rob, I have changed my Bugzilla 3.1.4+ installation to get the flag.id Please change two times in file /template/en/default/bug/show.xml.tmpl (line 58/59 and 101/102) <flag name="[% type.name FILTER xml %]" status="[% flag.status FILTER xml %]" to <flag name="[% type.name FILTER xml %]" id="[% flag.id FILTER xml %]" status="[% flag.status FILTER xml %]" Next I try to extend SaxMultiBugReportContentHandler in Mylyn
Created attachment 106905 [details] patch With this patch and the bugzillafile change from comment 14 it is possible to use Mylyn for existing (state = '?','+','-') flags. Comment12 is next to do.
Created attachment 106906 [details] mylyn/context/zip
Frank, are the changes posted in comment#14 to be included in an upcoming release of Bugzilla server?
http://bonsai.mozilla.org/cvsview2.cgi?root=/cvsroot&subdir=mozilla/webtools/bugzilla/template/en/default/bug&files=show.xml.tmpl&command=DIRECTORY http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/webtools/bugzilla/template/en/default/bug/show.xml.tmpl&rev=1.24&root=/cvsroot Looks like it hasn't been done yet in the Bugzilla trunk. You may want to update https://bugzilla.mozilla.org/show_bug.cgi?id=431363. Unless something has changed I'm unaware of, voting at BMO does not increase a bug's priority at all, rather it just helps change the state from UNCONFIRMED to NEW. Anyone with the proper access to that Bugzilla installation can update the bug from UNCONFIRMED to NEW. If you really need something to get done to Bugzilla code, it's best to chat with developers on irc://irc.mozilla.org/#mozwebtools (after filing a bug, of course - which you've already done). lpsolit and mkanat are the key people to talk with as they're "final say approvers" on code commits. It's likely that if you sumit a simple patch to the bug above, after reopening the issue, then setting the review flag to ?, it'll likely slide through easily. BTW - having flag support will make interacting with Bugzilla a lot easier for me as I use flags to track sprint work is done in. Keywords aren't enough for me, because they don't help me understand when a decision was made not to include a feature in a sprint and it's also not possible to set permissions based on keywords.
Rob: Where is this at? Can we get it into 3.1 with Frank's current patches? Does the behavior fail gracefully? Tentatively scheduling.
--- Comment 1 I see a number of lines of code commented out here, but there is no associated explanation why those new lines of code are commented out. I suggest either removing the (especially new) commented out code, or at least explaining why the lines are commented out as a header to the comment block(s). --- Comment 2 if (state != null) { options.add(""); options.add("?"); options.add("+"); options.add("-"); } The problem here is a flag may not be requestable ("?"). There are also times when a reader can see a flag but can't set it. Each of these settings is configurable on a per-flag basis. This is a lot better than nothing, but it deserves at least a TODO to detect what the real list of options should be per-flag. --- Review Result r- --- Note: While attempting to submit this comment to the patch (https://bugs.eclipse.org/bugs/attachment.cgi?id=106905), I was told I couldn't edit the patch. It seems permissions in this installation could be set up a little better to allow comments on patches. In open source, I'd rather allow anyone to do a review even if that review is invalid to encourage reviewers to participate (and provide mentoring) than to prevent reviews.
Sorry , I must create an new complete patch(one class was not included).
Created attachment 117410 [details] complete patch here is the complete patch. Two things are left open (I need help here). 1) the size of the textfield of the requestee is to small 2) the order of the Flags is not the same as within HTML
Created attachment 117411 [details] mylyn/context/zip
Created attachment 117457 [details] update of complete patch Sorry, I did not include support for not requestable flags
Created attachment 117458 [details] mylyn/context/zip
Great Frank, it will take me a bit to review (plan to before the weekend). In the mean time, could you build up some test coverage to exercise this new capability. Just email me if you need anything specific done to the test repos.
(In reply to comment #14) > Hi Rob, > > I have changed my Bugzilla 3.1.4+ installation to get the flag.id > > Please change two times in file /template/en/default/bug/show.xml.tmpl (line > 58/59 and 101/102) > > <flag name="[% type.name FILTER xml %]" > status="[% flag.status FILTER xml %]" > to > <flag name="[% type.name FILTER xml %]" > id="[% flag.id FILTER xml %]" > status="[% flag.status FILTER xml %]" > > Next I try to extend SaxMultiBugReportContentHandler in Mylyn Sorry I did not report this as an request to the Bugzilla Team. Now I create an Task for this (https://bugzilla.mozilla.org/show_bug.cgi?id=465219) We have to wait until this is fixed.
Created attachment 119011 [details] patch for both flagtypes With the next Bugzilla Version (>3.2rc2) bug https://bugzilla.mozilla.org/show_bug.cgi?id=465219 is included so we can support flags.
Created attachment 119012 [details] mylyn/context/zip
(In reply to comment #28) > Created an attachment (id=119011) > patch for both flagtypes > > With the next Bugzilla Version (>3.2rc2) bug > https://bugzilla.mozilla.org/show_bug.cgi?id=465219 is included so we can > support flags. Now that Bugzilla 3.2 is released we can update the testinstallation.
Perfect, I'll install and then start the review of your patch Frank. Great job coordinating this with the bugzilla.org crew!
Created attachment 119222 [details] minor update Just added some author tags etc. Looking great here Frank. Due to the size of the patch we'll need to submit for IP review.
Filed CQ 2866
(In reply to comment #33) > Filed CQ 2866 > All changes in the patch submitted in comment#28 were authored by me and I have the right to contribute this code to Eclipse.
CQ has been approved. Patch applied, ip log updated (cq noted). Frank, you've done a tone of excellent work here. With the paper work out of the way we can get down to the nits! * There appears to be a failure when submitting the blank flag option back to the repository (flag status for flag ID #1 is invalid). This may also be the source of the test failing in BugzillaRepository32Test? * We may need to consider a custom part to display the flags together, perhaps then we could use the ids to help order the flag layout consistently?
Refinement of this feature to take place on bug#258712. Marking resolved.
Hi, Any chance of this getting back-ported to the 3.0.x stream? Is the patch relatively self-contained? If so and if I did the work to merge it, would someone be able to look it over for me? The reason I ask is because Red Hat bugzilla has flag support and the Fedora processes use them a lot. Thanks, Andrew
There are no plans to backport this (since it is more of a new feature than a bug fix, at least from Mylyn perspective). Additionally, we're still working out the rough edges (tune into bug#258712 for lastest activity).
The 3.1 release with flag support will become available on March 4th, two weeks after 3.0.5 will go out.
(In reply to comment #39) > The 3.1 release with flag support will become available on March 4th, two weeks > after 3.0.5 will go out. Oh, I didn't realize there'd be a 3.1 release. I was assuming 3.0.5 would be the last Ganymede Mylyn release. I'll package up a recent 3.1 build and ask some Fedora people to give it a shot to verify it fixes the issues they've been seeing. Thanks.
The 3.1 release will not be part of the release train but it will be backwards compatible with 3.3: http://www.eclipse.org/projects/project-plan.php?projectid=tools.mylyn It is likely that this will also apply to the 3.2 release which will be released for Galileo and support Eclipse 3.5, 3.4 and 3.3.
Thank you for supporting the flags now in the editor, we're using them a lot ;-) Is there a way to use them in queries? We'd like to specify a "review-queue" query with the "review?" flag. Unfortunately this URL based query does not work (it times out): https://bugs.eclipse.org/bugs/buglist.cgi?field0-0-0=flagtypes.name;classification=Modeling;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;version=3.0;type0-0-0=equals;value0-0-0=review%3F;component=CDO;component=Net4j;product=EMF
Oh, I found out what might have happened: The new bugzilla seems to use ";" to separate fields, instead of "&". After converting the semicolons to ampersands my Mylyn query is working again ;-)
