Thoughts about bug email

[Klaas Freitag]

Hi,

I saw that it is on the TODO to incoorperate my old bug_email.pl script better
in Bugzilla. Since we here at SuSE and some other sites seem to use it,
I am currently trying to rewrite it to meet the needs of the new bugzilla.
The first step is to replace the functionality of the existing bug_email.pl
(adding bugs and comments to bugzilla) and to fix some bugs of it. In the
future, I like to make it possible even to switch stati by the tool.

Here are some thoughts about and I kindly ask for comments.

The new bug_email.pl should not only be a email script but more general
a commandline import script. It takes a bug in xml format following the
bugzilla.dtd and inserts it into a bugzilla.

To import a bug from an email needs only a conversion from the mime format to
the xml format, which is piped into the createBug script.

In order to be as independent from the bugzilla server as possible, I try to
avoid that the command line create bug script needs
a.) access to the bugzilla code base like CGI.pl etc.
b.) a connection to bugzillas database
c.) other access to the bugzilla server than over http.

That can be achieved by submitting bugs by  a scripted user agent calling
post_bug.cgi on the bugzilla server and transmitting the neccessary parameters.
The post_bug.cgi script inserts the bug to the database and notifies the
assignee (what was not done by bug_email.pl) and does all the stuff now
and in future needed.

One problem still remains: Checks for valid versions, products etc. that
comes in the xml file. The solution can be to have a script sendVersionTable.cgi
on the server, that sends the data/versioncache file to the client. The
client than saves it to a file and 'requires' it in the perl code as
usually. With the contents of the file, a lot of checks are possible,
especially if a variable %defaults exists, which holds the default values for
some bug attributes.

The described functionality works already with my test code here, which is
very alpha and needs error checking etc. But if somebody is interested, I like
to send it over.

The next step for me is to analyse the output of post_bug.cgi to check if the
action was successfull. It is not very comfortable to parse the 'human
readable' html code returned for default. Is it possible with the templates
to return a easy parseable output like xml depending on a flag coming with
the request indicating that the bug create request comes from a script?

Thanks for comments,

Klaas


-- 
  Wenn du einen Schneck behauchst                          Klaas Freitag
  Schrumpft er ins Gehaeuse,               *        mail freitag at suse.de
  Wenn du ihn in Kognak tauchst,                    SuSE Labs, Nuernberg
  Sieht er weiße Maeuse - Ringelnatz, Ueberall                         #