Added template support for bug creation

[sridhar]

A new bug can now be created using the supplied
template file. The template file needs to contain
all the required parameters needed by bugzilla.

Optional fields can also be supplied.

[williamh]

I really like this feature, but I have a couple of suggestions.

Please avoid bare except clauses, e.g. not "except:" but "except foo:" or "except foo as error:". Look at configfile.py for examples of this.

You might document the template handling code a bit more. Why are you using RawConfigParser instead of ConfigParser? What is going on with the lambda (I'm not really familiar with lambda, so documenting this in particular would be useful).

Thanks much.

[sridhar]

Thanks William,
I'll fix the exception handling.

The RawConfigParser was used under the assumption that the custom fields can be in upper case. The default parser converts everything to lower case. The lambda just specifies that the key from the config should be kept as is.
I don't know if this fixed (https://bugzilla.mozilla.org/show_bug.cgi?id=373869), but I removed any assumptions from the code. I'll add this in the comment.

[williamh]

I traced the bug you cited above to the Bugzilla 3.0 release notes [1]. It looks like custom field names must be in lower case, so I think we can get away with using ConfigParser instead of RawConfigParser unless that has changed in newer releases. You might want to check the newer Bugzilla releases and update this p/r.

Thanks for working on this. :-)

[1] https://www.bugzilla.org/releases/3.0/release-notes.html

[sridhar]

Sure. Let me check with the owners on bz irc/mailing lists.

[sridhar]

According to https://www.bugzilla.org/docs/4.4/en/html/api/Bugzilla/WebService/Bug.html#search
: "Some Bugzillas may treat your arguments case-sensitively, depending on what database system they are using. Most commonly, though, Bugzilla is not case-sensitive with the arguments passed (because MySQL is the most-common database to use with Bugzilla, and MySQL is not case sensitive)."

The fields themselves seem to be case insensitive. I'll revert it to regular ConfigParser.

[sridhar]

Hi William,
Let me know if you need me to change something else in this commit.

• Sridhar

[williamh]

The [Default] section of the template seems a bit unclear. What is going on with the type setting?

[sridhar]

Typically bugs for the features/components have different owners, qa etc (infra/platform/os/ui/cli). There could have been two approaches to this:

1. Have separate files for different components/types/features. This gets messy pretty soon. (Used this in one of my earlier companies)
2. Have types defined within the same file and refer to it. This is a cleaner approach.

In the type setting, one would just refer to the type/component of the bug they are going to create. And the same file will have multiple sections for the type of the bug.

[williamh]

What happens if there are multiple sections in the template file? Do I have to edit the default section every time I want to use a different section?

Also, what happens if there is no default section?

[sridhar]

Yes, default section have to be edited every time you want to use a different section. The file has to be edited each time to change the description and summary also.

If the file doesn't have a default section, then it'll exit out.

[sridhar]

Please let me know if this patch works for you.