Bug 816484 - Bug::get XMLRPC call does not return any result
Bug::get XMLRPC call does not return any result
Status: CLOSED DUPLICATE of bug 816038
Product: Bugzilla
Classification: Community
Component: WebService (Show other bugs)
4.2
Unspecified Unspecified
unspecified Severity medium (vote)
: ---
: ---
Assigned To: PnT DevOps Devs
:
Depends On:
Blocks: BZ42
  Show dependency treegraph
 
Reported: 2012-04-26 04:43 EDT by Martin Kosek
Modified: 2013-06-23 21:47 EDT (History)
1 user (show)

See Also:
Fixed In Version: 4.2.1-0.b28
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-04-26 05:23:25 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Martin Kosek 2012-04-26 04:43:41 EDT
Description of problem:

Bug.get XMLRPC call did not return a bug result or any failure even though the bug is in Bugzilla database (as verified in Web UI):

$ python
Python 2.7.2 (default, Oct 27 2011, 01:40:22) 
[GCC 4.6.1 20111003 (Red Hat 4.6.1-10)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
...
>>> proxy
<ServerProxy for partner-bugzilla.redhat.com/xmlrpc.cgi>
>>> proxy.Bug.get({'ids' : [688765]})
{'faults': [], 'bugs': [{}]}


Version-Release number of selected component (if applicable):
4.2.1-0.b27

How reproducible:


Steps to Reproduce:
1. Run Bug.get XMLRPC call
2.
3.
  
Actual results:
No Bug is returned

Expected results:
A Bug with given ID is returned

Additional info:
Comment 1 Martin Kosek 2012-04-26 05:13:19 EDT
I just realized that the call returns the result if I specify the fields that should be returned:

>>> proxy.Bug.get({'ids' : [688765], 'include_fields': [ 'id', 'summary', 'status', 'description']})
{'faults': [], 'bugs': [{'status': 'MODIFIED', 'description': 'Description of problem:\nAfter creating a asfdb record with ipa dnsrecord-add, the record does not seem to be resolvable by dig. \n\nVersion-Release number of selected component (if applicable):\nipa-server-2.0.0-14.el6.x86_64\n\nHow reproducible:\nalways\n\nSteps to Reproduce:\n1. ipa dnsrecord-add newzone afsdb --afsdb-rec "interesting.zone.com."\n2. dig AFSDB afsdb.newzonezone \n\n  \nActual results:\n;; QUESTION SECTION:\n;afsdb.newzone.\t\t\tIN\tAFSDB', 'id': 688765, 'summary': '[RFE] afsdb records to not seem to be resolvable.'}]}

Is this intentional? I would expect that at least some basic attributes would be returned with default "include_fields".

Lowering the severity...
Comment 2 Simon Green 2012-04-26 05:23:25 EDT

*** This bug has been marked as a duplicate of bug 816038 ***
Comment 3 Simon Green 2012-04-26 05:25:29 EDT
(In reply to comment #1)
> Is this intentional? I would expect that at least some basic attributes would
> be returned with default "include_fields".

Definitely not intentional. I made a change on Tuesday that accidentally caused this. It will be fixed in the next release.

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