Some of the formatting details required for bug submission via email
changed between Bugzilla 3.4 and 3.6. Bugzilla 3.4 requires lines of
the form '@fieldname = value', while 3.6 wants '@fieldname value'.
Also the field @bug_id in 3.4 becomes @id in 3.6.
Bugzilla up to and including 4.0 also recognises the 3.4 format. To save
surprises in the future, check the Bugzilla version and use the 3.6
format from all major versions >= 4. At some point we will
drop support for Bugzilla prior to 3.6 and support the new format only.
Add a second regular expression used when scanning change comments.
Bugs matched by this new regular expression have the bug comments and
optionally hours updated as with the first regular expression, but they
are also marked as fixed.
The bug status and resolution to set to mark a bug as fixed can be
configured. By default status is set to RESOLVED and resolution to
FIXED, the default Bugzilla settings.
For example, a change comment containing 'Fixes 1234 h1.5' will be
added to bug 1234, the bug will have its working time increased by
1.65 hours, and the bug will be marked RESOLVED/FIXED.
Change comments may contain both bug update and fix instructions. If
the same bug ID occurs in both, the last instruction found takes
precedence.
The patch adds new bug states 'bug_status' and 'resolution' and actions
to update them to the XMLRPC and XMLRPC/email access methods. XMLRPC does
not support marking bugs as fixed when used with Bugzilla versions prior
to 4.0. When used with an earlier Bugzilla version, a warning is issued
and only comment and hours updated.
If an 'hours' group is present in the bug matching regular expression,
and that group contains a float value, update the bug working time in
Bugzilla with those hours.
The patch adds a key 'hours' to the bug state dictionary, and adds
support for the key to the XMLRPC and XMLRPC/email access methods.
The MySQL access method is not supported; a warning is given.
As a first step to allowing comment text to update bug state, rework the
Bugzilla access interface to use a dictionary keyed on bug ID. Dictionary
entries will contain new state info in future changes.
Python 2.7 introduced support for gzip encoding in xmlrpclib.Transport.
We do our own handling of responses, and don't currently support gzip encoding.
So to run successfully under Python 2.7 with a web server configured
to gzip encode, stop XMLRPC requests from announcing gzip encoding support.
Inadvertently support is currently only for https. For some reason I
thought xmlrpclib.SafeTransport did http and https, but it is https only.
So create http and https XMLRPC transports that retain cookies. Decide which
to use by inspecting the Bugzilla URL.
Correct typo in numbering list of access methods.
Convert a section reference and a template parameter reference into
literal text, for consistency with other use.
Use consistent sample domains and wording in all configuration examples.
Add missing template and strip parameters to XMLRPC examples and correct
Bugzilla URL key in XMLRPC+email.
If Bugzilla has its email interface configured, an email can be used
to update bugs. If the From: address in the email matches a valid user
email, Bugzillas make the update as that user. So comments attached to a
bug appear under the name of the user making the change, and the user
does not receive email about the change, exactly as if they had made
the change via the web interface.
So add a modified XMLRPC mode that uses email to modify bugs. The format
of the mails is documented in the Bugzilla email_in.pl specification.
Briefly, initial non-blank lines in the message body starting
'@<field> = <value> modify bug fields. A blank line signals the end of
the command lines, and the rest of the message is used as bug comment.
Invoke the same Mercurial user to Bugzilla user email mapping
currently used in the MySQL mode.
All other processing - checking the bug numbers, checking user ids, etc.
continues to be done via XMLRPC.
Add support for access to Bugzilla via the XMLRPC interface.
This requires a single username and password used to log in to Bugzilla,
plus the URL of the Bugzilla installation. Commit messages are added to
bugs as before, but security only permits them to be added as the
username used to log in.
Prepare for the addition of other Bugzilla access methods by localising
direct MySQL database access inside an access class.
Provide a base access class largely to document the methods required for
a class implementing a particular access method.
Rename the 'bugzilla_<version>' classes to 'bzmysql_<version>' to
emphasise that they are doing access via direct manipulation of a
MySQL database.
Bug IDs are collected into a set, and then silently converted in
filter_real_bug_ids() into a list. For consistency, keep them in
a set throughout and update the docstrings to say that.
The method really removes from the list of bugs any that already have
comment text referencing the changeset in question. Rename it to
filter_cset_known_bug_ids().
Trying as much as possible to consistently:
- use a present tense predicate followed by a direct object
- verb referring directly to the functionality provided
(ie. not "add command that does this" but simple "do that")
- keep simple and to the point, leaving details for the long help
(width is tight, possibly even more so for translations)
Thanks to timeless, Martin Geisler, Rafael Villar Burke, Dan Villiom
Podlaski Christiansen and others for the helpful suggestions.
