Open Bug 643570 Opened 13 years ago Updated 10 years ago

Bugzilla Integration Plugin for QMO (Wordpress)

Categories

(quality.mozilla.org :: Website, defect)

Product:
quality.mozilla.org
Component:
Website
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: abillings, Assigned: apodgorny)

References

Details

Attachments

(2 files, 3 obsolete files)

Bugzilla Aggregator. Version 02.
12.27 KB, application/zip
Details
bugzilla.php
1.27 KB, text/php
Details 
The goal is to integrate statistics from Bugzilla on a per-wordpress/buddypress user basis to better identify community member involvement around quality-related tasks.

This requires a Wordpress plugin that can speak to the Rest APIs that Bugzilla uses in order to pull data on open bugs from Bugzilla.

Requirements

1. Uses new *Bugzilla address* field from user profile on QMO
2. Queries Bugzilla for bugs associated with this e-mail address
3. Pulls aggregate data (not entire bug details) into new table in QMO's Wordpress DB
4. Data is displayed as wordpress shortcode/templatable text that can be added to Wordpress pages and have a setting to specify user in shortcode so it can be embedded in a profile page.
5. If no data is available for an explicitly specified user, states that no data is available and to check that e-mail address configured.
6. Aggregate numbers displayed with shortcode/template text should be hyperlinkable to bugzilla results page that will present bugs that are being aggregated (no need to store bug details in DB).

Proposed initial data to be pulled per user and displayed in version 1 of plugin:

1. Bugs opened (ever)
2. Bugs opened within last x days (probably 30)
3. Bugs confirmed (ever)
4. Bugs verified (ever) 

Development Work

1. Creation of plugin (webdev)
2. Integration with QMO theme on each user profile page in new "Metrics" tab (Craig Cook?) 

Open question: Is it possible to show bug statistics on QMO Team pages (which are Buddypress groups) of users who have joined team as an aggregate (i.e. Bugs opened by team members ever or in last 30 days)? This could be in a "Metrics" tab within the team/group page just as on the user profile page.

When this is done, it might be useful to kick this out to the Wordpress community as a contribution as well.
Blocks: 643584
Assignee: nobody → apodgorny
Alex:

Can you review the requirements for this bug and let us know if you need any clarification?

Thanks,
Chris
Alex:

Can you provide us an update on the development of this plugin? We need to get an ETA from you on when the team can review what you have created so that we can accurately plan the next phases.

Thanks,
Chris
Alex: Also, this plugin is part of the Q2 goal and we only have a 3 weeks left in this quarter.
From Alex's email:

I have created the plugin and now it is capable of connecting to bugzilla with the following configuration:

Bugzilla Url
Bugzilla Username
Bugzilla Password

And it is capable of receiving the information about bugs that have current user as:

Bug Creator
Bug Assignee

I understand that you would like to store this info into the database. My current dilemma is developing the schema so that it would not be clugged by the overwhelming amount of the details in the bug record.

My current plan is to store serialized info into a blob and separately add fileds such as 

Assignee, 
Creator, 
Bug Id, 
Record update date 
Creation date 

For searching, presuming that the database will play a role of cache, I would need your approval on this minimal set of searchable fields to establish a query string to use as key in the records. Please let me know if the above list is sufficient.
(In reply to comment #5)
 
> For searching, presuming that the database will play a role of cache, I
> would need your approval on this minimal set of searchable fields to
> establish a query string to use as key in the records. Please let me know if
> the above list is sufficient.

Al, can you advise?
(In reply to comment #5)
> From Alex's email:
> 
> I have created the plugin and now it is capable of connecting to bugzilla
> with the following configuration:
> 
> Bugzilla Url
> Bugzilla Username
> Bugzilla Password

I'm not sure of what the above means, exactly.

Leaving aside any and all other features, I need to be able to query bugzilla by bugzilla e-mail address (which is normally the username) and get public bug data back. One of the primary design considerations is that *no* password information would be collected by this plugin, thus avoiding any and all security issues by only consuming public bug data and not storing any passwords or private credentials within wordpress. Reading the above, it isn't clear that this need is being met. Am I misunderstanding?
 
> And it is capable of receiving the information about bugs that have current
> user as:
> 
> Bug Creator
> Bug Assignee
> 
> I understand that you would like to store this info into the database. My
> current dilemma is developing the schema so that it would not be clugged by
> the overwhelming amount of the details in the bug record.
> 
> My current plan is to store serialized info into a blob and separately add
> fileds such as 
> 
> Assignee, 
> Creator, 
> Bug Id, 
> Record update date 
> Creation date 
> 
> For searching, presuming that the database will play a role of cache, I
> would need your approval on this minimal set of searchable fields to
> establish a query string to use as key in the records. Please let me know if
> the above list is sufficient.

Based on the spec (https://wiki.mozilla.org/QA/QMO/QMO_4.0), here is what I need for the plugin that is relevant here. This is an except.

Requirements

Pulls aggregate data (not entire bug details) into new table in QMO's Wordpress DB
Aggregate numbers displayed with shortcode/template text should be hyperlinkable to bugzilla results page that will present bugs that are being aggregated (no need to store bug details in DB). 

Proposed initial data to be pulled per user and displayed in version 1 of plugin:

    Bugs opened (ever)
    Bugs opened within last x days (probably 30)
    Bugs confirmed (ever)
    Bugs verified (ever) 

Al's current comment: All of the four above functions should return simply a number that is usable in the Wordpress template and hyperlinks back to a page that brings up the bugzilla query that shows the details on bugzilla itself.

In other words, If bugs opened for User X is "40", that "40" should just show "40" with a hyperlink to a Bugzilla search page that shows "Bugs opened by User X." From there, people could drill as deep as they want because they'll actually be on Bugzilla.

I'm not sure if the data being stored in the Wordpress DB, as proposed above, really matches to this need. We don't need to pull much data. We just need to create aggregate numbers based on opener, opened data, confirmation by user, and verified by user with links back to bugzilla.

Does this make sense?
@Al: This makes sense to me and your requirements is exactly how I read it too. I will get a phone call set up with Alex to make sure we are all on the same page.
Documentation links:

http://www.bugzilla.org/docs/4.0/en/html/api/Bugzilla/WebService.html (search for "logging in")

From Bugzilla API person: "If for example you do a Bug.get on a public bug in Bugzilla, it will return the bug's data back. But if it is private it will throw an error that you must login first."
Notes from the meeting:

1. Break plugin into two pieces:
   a. PHP script for cron job that requests aggregated data and polulates the db with it
   b. Redo the plugin to pull the cached data from the DB.

2. Enable anonymous access for the script to the bugzilla
Progress: got the webservice to return data anonymously. Turns out the library adopted from another mozilla project had a logical error when it comes to omitting login step for anonymous requests. 

Created new schema for aggregated data.

Proceeding to write the script to populate database. 

Having a question: where will my script get the list of all wp users to get aggregate data for?
Is there a table that i can read it from? If so, where do I find the schema?
(In reply to comment #11)

> Having a question: where will my script get the list of all wp users to get
> aggregate data for?
> Is there a table that i can read it from? If so, where do I find the schema?

They're kept in the WordPress database, in the wp_users table. See  http://codex.wordpress.org/Database_Description#Table:_wp_users

Note that the "wp_" prefix is variable, not hardcoded, so you'll want to get $table_prefix from wp-config. 

Each user also gets a status assigned to indicate whether they're active or inactive. We probably only need to fetch data for active users (those who have completed registration, not spammers or bots or failed signups).
Please verify my interpretation of the queries:

    Bugs opened (ever):
As a CREATOR of the bug, number of bugs existing with any status in all times
    Bugs opened within last x days (probably 30):
As a CREATOR of the bug, number of bugs existing with any status in last 30 days
    Bugs confirmed (ever):
As an assignee (ASSIGNED_TO) of the bug, number of bugs existing with IS_CONFIRMED = 1
    Bugs verified (ever):
As a QA_CONTACT of the bug, number of bugs existing with status VERIFIED
(In reply to comment #13)
> Please verify my interpretation of the queries:
> 
>     Bugs opened (ever):
> As a CREATOR of the bug, number of bugs existing with any status in all times
>     Bugs opened within last x days (probably 30):
> As a CREATOR of the bug, number of bugs existing with any status in last 30
> days

As long as the open date is within the last 30 days.

>     Bugs confirmed (ever):
> As an assignee (ASSIGNED_TO) of the bug, number of bugs existing with
> IS_CONFIRMED = 1

Assignee doesn't matter. People confirm bugs that are not assigned to themselves. We should be watching if the person in question marked the bug as confirmed only.

>     Bugs verified (ever):
> As a QA_CONTACT of the bug, number of bugs existing with status VERIFIED

 QA Contact is not relevant. That field isn't actually used for anything useful by anyone. We should be tracking bugs where the individual in question changed the resolution status to verified.
To my knowledge, Bugzilla API does not provide direct information about person who confirmed or verified the bug, however we can do compound queries asking for bugs with a particular "reporter", "creator", "assignee" or "qa contact" in one clause and in it's status in the other.

That raises two questions:

Question 1: is the person who confirms the bug necessarily among the above list of roles? If yes, which one?

Question 2: is the person who verifies the bug necessarily among the above list of roles? If yes, which one?
Progress: coding is done, documentation is done as well. The last things that remain uncertain are the queries to bugzilla. (See prev. comment)
(In reply to comment #15)
> That raises two questions:
> 
> Question 1: is the person who confirms the bug necessarily among the above
> list of roles? If yes, which one?

 No. People look for unconfirmed bugs in certain product areas without any prior association with the bug.
 
> Question 2: is the person who verifies the bug necessarily among the above
> list of roles? If yes, which one?

 Same answer as #1.
In this case, I don't see a way to search for "confirmer" or "verifier" through API without parsing the history of all available bugs. How would you like me to proceed from here?
Alex: Can you post your latest code to github or another location that the team can get to? We know it is not complete and there are still some open questions. I am going to investigate the confirmer and verifier fields.
Alex: I talked to the Bugzilla folks and they said you should be able to retrieve the confirmer and verifier from the Bug.history API method. More info here:

http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/WebService/Bug.html#history

You will still have to parse the results, but it is also publicly accessible.
Yes, I know it is possible to do that, however this means that we would have to access sequentially each of half a million bugs contained in bugzilla by id every time the script runs. This could take a very long time, not to mention it could keep bugzilla server very busy. I can go ahead and implement that, but once again I am concerned about it's performance.

I am attaching a working copy of the plugin and the aggregator script herein.
Attached file Bugzilla Aggregator. Version 01. (obsolete) — 

    
    

    
  
Al/Craig: Do you want to push off the confirmer/verifier until a version 2 so we can try to get this out the door by the end of Q2? I'm going to vote yes. Please install version 01 from Alex and confirm it is what you are looking for.

Craig: You might as well integrate it into stage so we can test it out.

    
    

    
  
Craig, you can find readme.txt with installation instructions within one of the zips inside. Please feel free to ask me any additional questions, if any.

    
    

    
  
(In reply to comment #23)
> Al/Craig: Do you want to push off the confirmer/verifier until a version 2
> so we can try to get this out the door by the end of Q2? I'm going to vote
> yes. Please install version 01 from Alex and confirm it is what you are
> looking for.

Yeah, lets get rev 01 out the door.

Is there really no way to get the data for 02 without crawling tens or hundreds of thousands of entries?

    
    

    
  
Al: It seems like getting the data for 02 would be more complicated since you would have to get the history for all bugs, walk through the results, and find users in the results that are in the QMO database, and then count and aggregate numbers for each of the users. What makes it more complicated is that the history data is accessed for a bug ID or a set of bug IDs. There is no way to get the history for a particular user who confirmed a bug without getting all of the bug data and then finding that user in the history. A custom SQL statement could be written on the bugzilla side to do it I'm sure, but we have to work through the API. 

Alex: Is that how you interpret the complexity of getting this data?

    
    

    
  
I'm still not able to get this working and I'm not sure what I may be doing wrong. The database tables are empty. I'm also not sure how to display results; the readme doesn't contain a usage example, and the code from the previous readme doesn't work.

Alex, is there any way you can put this online somewhere and show me a working example? Do you have access to the QMO repository in Subversion?

Also, it would be good to bundle it all into a single folder to help keep the plugins folder tidy (we've got a lot of plugins).

    
    

    
  
Chris: yes, this is my interpretation as well. Either we ask them to add verifier and confirmer as search parameters to the API or we crawl the history :(

Craig, the usage example would be printing out the results of the function call like so:

<?php print_r(get_bugzilla_stats()); ?>

But if the table is empty, than something else has gone wrong. The easiest way would be to set up a time and work on installation together. Please send me an invite and we can do this over skype if you wish. My first guess is to blame the difference in the wordpress configuration. Like I said, I used a fresh wordpress copy for development.

As far as bundling it into a single folder, it is your choice, you can unzip the aggregator script into the bugzilla plugin folder. It should make no difference. I just assumed that you keep cron jobs in a separate place.

    
    

    
  
It might be worth asking the BMO team for an extension that adds the queries you need to the API, since it's going to be simpler and probably less resource intensive than crawling history.

    
    

    
  
Could you please point me in the direction of the right person?

    
    

    
  
(In reply to comment #28)
> Chris: yes, this is my interpretation as well. Either we ask them to add
> verifier and confirmer as search parameters to the API or we crawl the
> history :(

i'll investigate how much work is involved in adding these parameters to search for you.

    
    

    
  
I can take this one. Will look at the requirements and come back with a plan on rolling the changes out. We will create bugzilla.mozilla.org bugs for the changes needed so we can track them separately.

dkl

    
    

    
  
After discussing this one with other Bugzilla developers we think it is best for now to go the route of adding custom XMLRPC WebService API method(s) for returning the information you need for your plugin. The other alternative was to extend the search code on the backend to support querying on confirmer or verifier but with upcoming releases of Bugzilla, the code will likely be much different and our patches would need to be re-written. The API methods are more of a guarantee to continue to work.

That being said, what is the data that you would need the methods to return to satisfy your requirements? A simple count or a full list of bug ids? I feel the latter since you will be able to use that to make a buglist.cgi query that can take the user to the same bug list on BMO. (i.e. buglist.cgi?bug_id=BUG1,BUG2,...).

The API methods could be called:

BMO.getBugsConfirmer({ names => ['dkl@mozilla.com',...] })

BMO.getBugsVerifier({ names => ['dkl@mozilla.com',...] })

We could even combine them into one using some sort of flag to trigger the proper query but not really necessary at this point.

Sound good?

dkl

    
    

    
  
Thank you for investigating, David. The ideal solution would be to extend the search method, but if it is not the option, I would have to say a list of ids would be my best bet. At least we would not have to ask for additional modifications to the method should we need another piece of information from the bugs returned. We could just use Bug.get to request them one by one, should the need arise.

Will this patch be documented somewhere?

    
    

    
  
(In reply to comment #33) 
> That being said, what is the data that you would need the methods to return
> to satisfy your requirements? A simple count or a full list of bug ids? I
> feel the latter since you will be able to use that to make a buglist.cgi
> query that can take the user to the same bug list on BMO. (i.e.
> buglist.cgi?bug_id=BUG1,BUG2,...).

 I think the best solution for the widest use is a list of Bug IDs.
 
> The API methods could be called:
> 
> BMO.getBugsConfirmer({ names => ['dkl@mozilla.com',...] })
> 
> BMO.getBugsVerifier({ names => ['dkl@mozilla.com',...] })
> 
> We could even combine them into one using some sort of flag to trigger the
> proper query but not really necessary at this point.
> 
> Sound good?

 From my point of view, yes.

    
    

    
  


  
This version allows for a username being passed directly into the plugin function. For usage example see included readme.txt

        Attachment #541729 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached file
          
        bugzilla.php
        — 
      

    


  
Craig, I am adding two functions to produce urls to bugzilla bug search pages you requested. Usage examples are in the comments. Please replace existing bugzilla.php file in the plugin folder with this one.

    
    

    
  


  
Patch attached that adds new methods BMO.getBugsVerifier and BMO.getBugsConfirmer for use by QMO Wordpress plugin. 

Currently it returns a hash of email addresses each pointing to a list of bug ids that match for whichever method you use. 

Also it just does simple auth of the client to make sure they are logged in but will return another user's bug list since normally bug ids are ok and do not give away any sensitive information.

Question: Should we limit it to the user's own bug list and not allow others to get lists for someone else?

Please review
dkl

        Attachment #546170 -
        Flags: review?(glob)

    
    

    
  
(In reply to comment #38)
> Also it just does simple auth of the client to make sure they are logged in
> but will return another user's bug list since normally bug ids are ok and do
> not give away any sensitive information.
> 
> Question: Should we limit it to the user's own bug list and not allow others
> to get lists for someone else?

For our purposes on QMO we're specifically searching only public bugs and not passing any auth, so any private or security bugs are excluded. Essentially, QMO is an anonymous user, so every bug is treated as someone else's bug.

    
    

    
  
(In reply to comment #39)
> For our purposes on QMO we're specifically searching only public bugs and
> not passing any auth, so any private or security bugs are excluded.
> Essentially, QMO is an anonymous user, so every bug is treated as someone
> else's bug.

Ah ok. I missed earlier the part about public bugs only. That makes me feel better. I will submit a revised patch that only returns public ids. That does skew the results a little especially if the user in question is doing quite a bit of work verifying/confirming private bugs as well. So the numbers will seem lower than reality.

dkl

    
    

    
  


  
New patch the filters out private bug ids.

dkl

        Attachment #546170 -
        Attachment is obsolete: true

        Attachment #546170 -
        Flags: review?(glob)

        Attachment #546211 -
        Flags: review?(glob)

    
    

    
  
Comment on attachment 546211 [details] [diff] [review]
Patch adding new webservice methods for QMO (v2)

Review of attachment 546211 [details] [diff] [review]:
-----------------------------------------------------------------

are we better off taking this to a new bug which blocks this one, to avoid spamming the qmo team?

r- due to the broken select in getBugsVerifier.

::: extensions/BMO/lib/WebService.pm
@@ +14,5 @@
> +# by the Initial Developer are Copyright (C) 2011 the Mozilla Foundation. All
> +# Rights Reserved.
> +#
> +# Contributor(s):
> +#   Dave Lawrence <dkl@mozilla.com>)))

nit: )))

@@ +43,5 @@
> +    @user_objects = map { Bugzilla::User->check($_) } @{ $params->{names} };
> +
> +    # start filtering to remove duplicate user ids
> +    my %unique_users = map { $_->id => $_ } @user_objects;
> +    @user_objects = values %unique_users;

you can do this without the transient variable with:
  @user_objects = values %{{ map { $_->id => $_ } @user_objects }};

@@ +52,5 @@
> +                   FROM bugs_activity
> +                        LEFT JOIN bug_group_map 
> +                        ON bugs_activity.bug_id = bug_group_map.bug_id
> +                  WHERE bugs_activity.fieldid = ?
> +                        AND bugs_activity.added = 'VERIFIED'

this should be:
  AND bugs_activity.removed = 'UNCONFIRMED'
  AND bugs_activity.added = 'NEW'

@@ +81,5 @@
> +    @user_objects = map { Bugzilla::User->check($_) } @{ $params->{names} };
> +
> +    # start filtering to remove duplicate user ids
> +    my %unique_users = map { $_->id => $_ } @user_objects;
> +    @user_objects = values %unique_users;

drop the transient variable here too please.

@@ +130,5 @@
> +
> +=item B<Description>
> +
> +This method returns public bug ids that a given user has confirmed (changed from 
> +C<UNCONFIRMED> to C<NEW>) in the past. 

remove "in the past".

@@ +134,5 @@
> +C<UNCONFIRMED> to C<NEW>) in the past. 
> +
> +=item B<Params>
> +
> +You pass a field called C<names> that is a list of Bugzilla user accounts to find bugs for.

"user accounts" isn't clear enough in this context; it would be better to say:
  You pass a field called C<names> that is a list of Bugzilla login names to find bugs for.

@@ +138,5 @@
> +You pass a field called C<names> that is a list of Bugzilla user accounts to find bugs for.
> +
> +=over
> +
> +=item C<names> (array) - An array of strings representing Bugzilla user accounts.

again you need to s/user accounts/login names/

@@ +147,5 @@
> +
> +=over
> +
> +A hash of Bugzilla user accounts. Each account is an array of bug ids that the user has confirmed
> +in the past.

s/user accounts/login names/

@@ +167,5 @@
> +=back
> +
> +=back
> +
> +=head2 getBugsVerifier

my comments for getBugsConfirmer also apply to getBugsVerifier

        Attachment #546211 -
        Flags: review?(glob) → review-
Depends on: 672194

    
    

    
  
Comment on attachment 546211 [details] [diff] [review]
Patch adding new webservice methods for QMO (v2)

Moved work for the Bugzilla side of things to bug 672194.

        Attachment #546211 -
        Attachment is obsolete: true

    
    

    
  
the new BMO API methods are on our test instance at https://bugzilla-stage-tip.mozilla.org if you want to test them with your plugin. Let me know if you need any more details to set it up.

dkl

    
    

    
  
(In reply to comment #44)
> the new BMO API methods are on our test instance at
> https://bugzilla-stage-tip.mozilla.org if you want to test them with your
> plugin. Let me know if you need any more details to set it up.

Matter of fact, I would prefer if you definitely test this against bugzilla-stage-tip first before I commit to our production code. This will minimize on any changes if needed to our production servers to fix any problems. I will wait for your sign off.

dkl

    
    

    
  
Has anyone had a chance to test out the new API methods on bugzilla-stage-tip.mozilla.org with your plugin work?

dkl

    
    

    
  
David:

While trying to test this I got the following error back from the staging server:

"Application failed during request deserialization: no element found at line 1, column 0, byte -1 at /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/XML/Parser.pm line 187"

What's even more confusing is that the faultCode being returned is a string: "Client".

I'm having trouble figuring out what this means. Can you provide any help?

    
    

    
  
Just a shot in the dark, but are you using xmlrpc.cgi instead of jsonrpc.cgi in your server address? They both take similar data, just one expects XML and the other expects JSON. When I do simple tests on bugzilla-stage-tip it works for me.

Perl:

$callobj = {
    method => 'BMO.getBugsConfirmer',
    params => { names => [ 'abillings@mozilla.com ],
                Bugzilla_login => $username,
                Bugzilla_password => $password
              }
};

$res = eval { $rpc->call($url, $callobj) };

print Dumper($res->result);

Output:

$VAR1 = {
          'abillings@mozilla.com' => [
                                       '350942',
                                       '388809',
                                       '404758',
                                       '404766',
                                       '404840',
                                       '416649',
                                       '416839',
                                       '428842',
                                       '431691',
                                       '456705',
                                       '465875',
                                       '483510',
                                       '495784',
                                       '500782',
                                       '583683',
                                       '585819'
                                     ]
        };

    
    

    
  
The service seems to be working again, it might've been a temporary issue.

QMO is currently using non-authenticated methods to grab it's data. Can these methods be changed to not require authentication?

    
    

    
  
(In reply to comment #50)
> The service seems to be working again, it might've been a temporary issue.
> 
> QMO is currently using non-authenticated methods to grab it's data. Can
> these methods be changed to not require authentication?

Done. Should be live on bugzilla-stage-tip.mozilla.org very soon now.

dkl

    
    

    
  
(In reply to David Lawrence [:dkl] from comment #51)
> (In reply to comment #50)
> > The service seems to be working again, it might've been a temporary issue.
> > 
> > QMO is currently using non-authenticated methods to grab it's data. Can
> > these methods be changed to not require authentication?
> 
> Done. Should be live on bugzilla-stage-tip.mozilla.org very soon now.
> 
> dkl

Seems to be working for me. How long will it take to get these methods on the production Mozilla bugzilla instance?

    
    

    
  
(In reply to Michael Kelly [:mkelly] from comment #52)
> (In reply to David Lawrence [:dkl] from comment #51)
> > (In reply to comment #50)
> > > The service seems to be working again, it might've been a temporary issue.
> > > 
> > > QMO is currently using non-authenticated methods to grab it's data. Can
> > > these methods be changed to not require authentication?
> > 
> > Done. Should be live on bugzilla-stage-tip.mozilla.org very soon now.
> > 
> > dkl
> 
> Seems to be working for me. How long will it take to get these methods on
> the production Mozilla bugzilla instance?

If I commit them today the changes could possibly be live this Thursday which is our normal update time.

dkl

    
    

    
  
David:

Sounds good. 

We've been having speed issues with getting bug counts for users with large amounts of bugs; Bugzilla is taking many seconds to respond with the bug list for these users.

Would having some API functions that give only bug counts rather than a list of bug IDs be faster, and if so, can they be added to Bugzilla?

    
    

    
  
We can definitely add a parameter to the current API calls that will only return the count instead of all bug ids. This should be slightly faster, not to mention the smaller returned payload. The question then would be would returning the full list be the default behavior or the other way around. If we leave it as default we do just do something like:

$callobj = {
    method => 'BMO.getBugsConfirmer',
    params => { names => [ 'abillings@mozilla.com ],
                count_only => 1, 
                Bugzilla_login => $username,
                Bugzilla_password => $password
              }
};

$res = eval { $rpc->call($url, $callobj) };

print Dumper($res->result);

Output:

$VAR1 = {
          'abillings@mozilla.com' => 23
        };

I can put this on bugzilla-stage-tip.mozilla.org for testing.

dkl

    
    

    
  
Leaving the default as it is and making the count optional I think is best.

This would be added to Bug.search as well as BMO.getBugsConfirmer and BMO.getBugsVerifier, correct? Bug.search is the major pain point currently, as some of our users has hundreds or thousands of bugs. I would imagine using a count on the server side (making the DB do the work) would help here.

    
    

    
  
Pushed changes to bugzilla-stage-tip.mozilla.org to add the count_only param to BMO.getBugsConfirmer and BMO.getBugsVerifier so please give those a try.

To add support to Bug.search will take some more time and research as that is a core WebService API call. 

dkl

    
    

    
  
(In reply to Michael Kelly [:mkelly] from comment #56)
> This would be added to Bug.search as well as BMO.getBugsConfirmer and
> BMO.getBugsVerifier, correct? Bug.search is the major pain point currently,
> as some of our users has hundreds or thousands of bugs. I would imagine
> using a count on the server side (making the DB do the work) would help here.

Looking into adding the change Bug.search you request now. Can you give me some specific searchs that you or others do with Bug.search that I can use in my verification?

Basically my thinking is to just pass a new param to Bug.search called count_only => 1 which will just return an integer instead of a list of bugs. Let me know if this is different than what you need.

Thanks
dkl

    
    

    
  
When we use Bug.search we filter by creator and creation_time to get total bug count and bug count for the last 30 days.

Adding a count_only parameter sounds like it would be great.

    
    

    
  
Especially since we are timing out on queries (on our end) for some users.
Depends on: 681027

    
    

    
  
Ok, committed change that will allow bug count only for Bug.search. The API will look like this:

Bug.search({ product => 'Bugzilla', status => 'NEW', count_only => 1 });

returns

{ bug_count => 123 }

Without count_only, you get a list of bugs and their data.

Let me know if you have any problems with testing.

dkl

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: