Thoughts about bug email

[Christian Reis]

On Thu, Aug 22, 2002 at 03:16:17PM +0200, Klaas Freitag wrote:
> 
> 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.

It would still need to parse the email, at any rate, so I guess having
two files that worked together (probably a library) may be the best
approach. You'd end up with an XML parsing set of functions that did the
database operations, and the mail parser that took care of banging the
text into a decent format.

> 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.

Ahm, I start to understand your idea. But why is it important to have this
separate from the bugzilla server? Or is that just one of the design
goals? Do you think it will be a common case to have the mail handling
separate from the bugzilla server?

If it is deemed very important, I'd agree with moving to an HTTP
interface between mailparse and post_bug.cgi (if that's the current
plan, as I understand it).

> 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.

I'm not sure enough to comment on this. Keep in mind there are security
issues involved with this: would this not work for private products and
bugs?

> 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.

Would be nice to see this attached to the relevant bug :-)

> 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

We do that in mozbot for show_bug.cgi, but we may want to offer a
simpler API for RPC (since that's what we are doing here, I guess)

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL