If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

xml packet always return 0 from assigned_to

RESOLVED INVALID

Status

()

Bugzilla
Bug Import/Export & Moving
RESOLVED INVALID
7 years ago
7 years ago

People

(Reporter: sallyge, Unassigned)

Tracking

Details

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; .NET CLR 1.1.4322; .NET CLR 2.0.50727; CIBA; .NET CLR 3.0.04506.30)
Build Identifier: 3.6

We use a tool which use xmlrpc.cgi. The xml packet always returns 0 from assigned_to. In the Bugzilla version 3.6, I find the function assigned_to code is below:
sub assigned_to {
    my ($self) = @_;
    return $self->{'assigned_to_obj'} if exists $self->{'assigned_to_obj'};
    $self->{'assigned_to'} = 0 if $self->{'error'};
    $self->{'assigned_to_obj'} ||= new Bugzilla::User($self->{'assigned_to'});
    return $self->{'assigned_to_obj'};
}
But in database there is field "assigned_to", no such field "assigned_to_obj".

Reproducible: Always

Steps to Reproduce:
1.use xmlrpc.cgi to return xml packet
2.the assigned_to always returns 0 from xml packet
Actual Results:  
assigned_to = 0

Expected Results:  
assigned_to = user login address

Comment 1

7 years ago
  I'm sorry, you will have to be more specific. What XML-RPC function are you calling? What arguments are you sending?
(Reporter)

Comment 2

7 years ago
The API method we're calling is the "Bug.get_bugs" method and the parameter we're requesting a value for is: "assigned_to_id".

Comment 3

7 years ago
I'm sorry, what does "parameter we're requesting a value for" mean?

As you can see, assigned_to_id is not returned by that function:

http://www.bugzilla.org/docs/3.6/en/html/api/Bugzilla/WebService/Bug.html#get
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INVALID
(Reporter)

Comment 4

7 years ago
Sorry, because the external function used the "internals" property which gives direct access to the Bug object, so we're actually asking for internals.assigned_to_id which should return the numeric ID of the username. This works in Bugzilla v3.0+ whose Bug object has assigned_to_id property but due to lack of thorough test this does not work in Bugzilla v3.4+ whose Bug object has no property assigned_to_id. 
This is our fault. You can close the bug. Thanks!
You need to log in before you can comment on or make changes to this bug.