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.
During 2.17, Bugzilla ditched the old 'processmail' script. With 2.18
contrib/sendbugmail.pl arrived in its place.
For notification emails to work properly, sendbugmail.pl requires as
its second parameter the Bugzilla user who made the commit. Otherwise
the user will not be recognised as the committer, and will receive
notification emails about the commit regardless of their preference
about being notified on their own commits. This parameter should be given
to processmail also, but wasn't for historical reasons.
Add new config with the local Bugzilla install directory, and provide
defaults for the notify string which should work for most setups.
Still permit notify string to be specified, and for backwards
compatibility with any extant notify strings try first interpolating
notify string with old-style single bug ID argument. Add new 2.18
support version to introduce sendbugmail.pl.
In other words, this update should be backwards-compatible with existing
installations, but offers simplified setup in most cases. And as a bonus
Bugzilla notification emails will be dispatched correctly; notifiers will
not receive an email unless configured to do so.
Revise the comments detailing module usage at the start of the Bugzilla
extension into extension help text.
Expand the detail given on extension settings, in an attempt to permit
the user to configure successfully without having to study the extension
code. Show a sample configuration as well.
Bugzilla 3.2 changes the type of all MySQL tables it uses from MyISAM
to InnoDB. MyISAM does not support transactions, and performs an implied
commit after each update. InnoDB does support transactions, and so
exposes a bug where changes to the Bugzilla database were not committed,
and so with 3.2 are lost when the database connection closes.
old scheme (False/None/0/'' == fail) made coding style
unnatural, did not allow use of mercurial commands as hooks.
new scheme (False/None/0 == pass) is pythonic, does not require peculiar
"return True" at ends of hooks, allows hooks like this:
[hooks]
# update working dir after push into this repo
changegroup.update = python:mercurial.commands.update
hook updates bugzilla bugs when it sees commit comments that mention
bug id, such as "i fixed bug 77".
only bugzilla 2.16 supported yet, but easy to extend. bugzilla versions
have different schema, i have not used later than 2.16.