In response to: http://globau.wordpress.com/2012/10/09/bugzilla-mozilla-org-integration-best-practices/ OrangeFactor uses bzapi in the following places: 1) https://hg.mozilla.org/automation/orangefactor/file/c492511a8bb6/server/handlers.py#l438 437 if singlebugre.match(bzquery): 438 apiURL = BZAPI_SERVER + "bug?id=" + bzquery + "&include_fields=id,summary,status&whiteboard=[orange]" 439 else: 440 apiURL = BZAPI_SERVER + "bug?quicksearch=" + bzquery + "&include_fields=id,summary,status&whiteboard=[orange]" 2) Via it's use of bzcache: a) https://hg.mozilla.org/automation/orangefactor/file/c492511a8bb6/server/handlers.py#l365 365 orange_bugs = bzcache.get_bugs(list(buglist), whiteboard='[orange]') b) https://hg.mozilla.org/automation/orangefactor/file/c492511a8bb6/server/handlers.py#l531 531 data['bugs'] = bzcache.get_bugs(list(bugids)) c) https://hg.mozilla.org/automation/orangefactor/file/c492511a8bb6/server/handlers.py#l837 837 orange_bugs = bzcache.get_bugs(map(lambda x: str(x), 838 self.correlations.keys()), 839 whiteboard='[orange]') d) https://hg.mozilla.org/automation/orangefactor/file/c492511a8bb6/server/update_testfailures.py#l71 71 bugdata = bzcache.get_bugs(bugs) At first glance: a) For #1, we use quicksearch= when we actually want summary= (presuming a not-logged-in user still searches comments as well when using quicksearch; which in this case is wasteful). b) For #1, we should use a keyword (but that's the already known bug 790571). c) The bzcache calls eventually end up at: https://hg.mozilla.org/users/jgriffin_mozilla.com/bzcache/file/15a2b7dae33c/bzcache/bzcache.py#l50 ...which limits columns to {id,summary,status,whiteboard}, plus bzcache uses pulse to avoid hitting b.m.o, so I don't think we need to worry about these. Glob, other than s/quicksearch/summary/ in #1, can you spot anything else?

i don't see anything else that would cause concerns, excellent work.

* In the "we're just searching for a single bug number" case, use "bug/123456" rather than a search for a single bug id. * If not a single bug number, now searches just the summary and not using quicksearch (which searches comments too) (Note: In the single bug case, we'll end up with "?&include_.....", but didn't think it was worth cluttering up further by splitting out the ampersand).

(Bah, sorry ignore the previous, json returned in each case wasn't the same) With this patch we now search just the summary and not using quicksearch (which searches comments too) + a bit of duplication removal.

Comment on attachment 670650 [details] [diff] [review] Patch v2 Review of attachment 670650 [details] [diff] [review]: ----------------------------------------------------------------- Cool. Please also replace the references to QuickSearch with "Bug summary" or something like that in the HTML & JS (including variable names like awaitingQuicksearchResponse, just for clarity).

Hmm the more I think about this, the more I think that having quicksearch is actually kind of useful, given we can do product/component searches etc (I've always thought about this OrangeFactor field as just a way to search the summaries, not other fields). Glob, is there a way to make the bzapi quicksearch not search comments, that way we could keep using it and still lower the load (though these are manually initiated queries, so it's not really that heavy as it is)?

(In reply to Ed Morley [:edmorley UTC+1] from comment #5) > Glob, is there a way to make the bzapi quicksearch not search comments, that > way we could keep using it and still lower the load (though these are > manually initiated queries, so it's not really that heavy as it is)? the only thing you can do right now is a per-user preference which toggles comment searching. on bmo this defaults to on (should probably default to off, but that's another story for another time). i suggest creating an account on bmo, toggling this preference, and authenticating with bzapi using that account. another option would be to wait for bug 803058 to be fixed.

Thank you for clarifying :-) I think given how infrequently (relatively) this feature is used, we might as well just wait for bug 803058 is fixed. Unassigning pending bug 803058.

Uses the new "--comments" feature added by bug 803058 (not quite yet in b.m.o production).

Comment on attachment 675219 [details] [diff] [review] Patch v3 Review of attachment 675219 [details] [diff] [review]: ----------------------------------------------------------------- Can't test this atm, but it looks good, and the patch in bug 807114 is based on this, so r+. :) Will test again once the Bugzilla --comments patch lands.

Seems to work well :-) Compare: https://api-dev.bugzilla.mozilla.org/latest/bug?quicksearch=debugger%20--comments&include_fields=id,summary,status&whiteboard=[orange] With: https://api-dev.bugzilla.mozilla.org/latest/bug?quicksearch=debugger&include_fields=id,summary,status&whiteboard=[orange]