Python 2.6 introduced the "except type as instance" syntax, replacing
the "except type, instance" syntax that came before. Python 3 dropped
support for the latter syntax. Since we no longer support Python 2.4 or
2.5, we have no need to continue supporting the "except type, instance".
This patch mass rewrites the exception syntax to be Python 2.6+ and
Python 3 compatible.
This patch was produced by running `2to3 -f except -w -n .`.
Extension authors (notably at companies using hg) have been
cargo-culting the `testedwith = 'internal'` bit from hg's own
extensions, which then defeats our "file bugs over here" logic in
dispatch. Let's be more aggressive about trying to give extension
authors a hint about what testedwith should say.
In the context of standalone Hg receiving a set of incoming changes, it makes
sense for the Bugzilla module to cache basic setup to avoid reconnecting
to Bugzilla for each change. After processing the changes, Hg will exit
and so the connection is short-lived.
But this doesn't work too well when used from a long-lived environment
such as hgweb or Kallithea where, for example, the connection can time out.
So take the simple approach, abandon the cache and do the basic setup on
each call. This fixes current problems with Kallithea.
Bugzilla 4.4.3 and later remove the old cookie based session authentication
from the Web Services API and replace it with a login token. The session
can now also be restricted to the originating IP.
Add the necessary to the extension so it works with 4.4.3 and later.
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().
