Bugzilla::WebService::Server::XMLRPC - The XML-RPC Interface to Bugzilla
This documentation describes things about the Bugzilla WebService that are specific to XML-RPC. For a general overview of the Bugzilla WebServices, see Bugzilla::WebService.
The XML-RPC standard is described here: http://www.xmlrpc.com/spec
The endpoint for the XML-RPC interface is the xmlrpc.cgi script in your Bugzilla installation.
For example,
if your Bugzilla is at bugzilla.yourdomain.com,
then your XML-RPC client would access the API via: http://bugzilla.yourdomain.com/xmlrpc.cgi
dateTime fields are the standard dateTime.iso8601 XML-RPC field.
They should be in YYYY-MM-DDTHH:MM:SS format (where T is a literal T).
As of Bugzilla 3.6,
Bugzilla always expects dateTime fields to be in the UTC timezone,
and all returned dateTime values are in the UTC timezone.
All other fields are standard XML-RPC types.
All functions take a single argument,
a <struct> that contains all parameters.
The names of the parameters listed in the API docs for each function are the <name> element for the struct <member>s.
Normally,
XML-RPC does not allow empty values for int,
double,
or dateTime.iso8601 fields.
Bugzilla does--it treats empty values as undef (called NULL or None in some programming languages).
Bugzilla accepts a timezone specifier at the end of dateTime.iso8601 fields that are specified as method arguments.
The format of the timezone specifier is specified in the ISO-8601 standard.
If no timezone specifier is included,
the passed-in time is assumed to be in the UTC timezone.
Bugzilla will never output a timezone specifier on returned data,
because doing so would violate the XML-RPC specification.
All returned times are in the UTC timezone.
Bugzilla also accepts an element called <nil>,
as specified by the XML-RPC extension here: http://ontosys.com/xml-rpc/extensions.php,
which is always considered to be undef,
no matter what it contains.
Bugzilla does not use <nil> values in returned data,
because currently most clients do not support <nil>.
Instead,
any fields with undef values will be stripped from the response completely.
Therefore the client must handle the fact that some expected fields may not be returned.