444389 - Allow product/component via command line and set default options

Status: NEW

(Bugzilla :: Incoming Email, enhancement)

Description

[Corris]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0
Build Identifier: 3.3

To make it easy on users who can't even handle a simplified bug entry form, we need a way to specify the product and component via the command line, so that we can define an email address for a specific product/component as "incoming email bugs".   we who use bugzilla can then be notified of the bug by email, and then fix the product/component.  the default behavior returns a mail which is confusing to users.

Reproducible: Always

Comment 1

[Corris]

Attachment: the patch

Comment 2

[Max Kanat-Alexander]

This sounds like basically a good idea.

If you'd like to get your patch into the codebase, see:

  http://wiki.mozilla.org/Bugzilla:Developers

Comment 3

[Corris]

Attachment: patch_v1.1

Comment 4

[Max Kanat-Alexander]

Comment on attachment 328858 [details] [diff] [review]
patch_v1.1

>+    if ( $switch{defaults} ) {
>+        $fields{version} = 'unspecified';
>+        $fields{rep_platform} = 'All';
>+        $fields{op_sys} = 'All';
>+    }

  Those are not always the defaults. email_in already chooses defaults for you if the field isn't specified, using the defaultopsys and defaultplatform parameters.

  There is not always a version called "unspecified".

  I think we should come up with another way to do this instead of a "-d" switch.

Comment 5

[Corris]

ok, we can lose the platform and op_sys, that's fine.  

I originally thought a version flag, --version, but the short version '-v' was taken already by the verbose flag.  maybe -n ?  ( but that usually means --dry-run )  or maybe -r ?

Comment 6

[Max Kanat-Alexander]

(In reply to comment #5)
> I originally thought a version flag, --version, but the short version '-v' was
> taken already by the verbose flag.  maybe -n ?  ( but that usually means
> --dry-run )  or maybe -r ?

  You could just not have a short one for version.

Comment 7

[Frédéric Buclin]

(In reply to comment #0)
> To make it easy on users who can't even handle a simplified bug entry form

Unlike mkanat, I don't like the idea of this command line alternative. If product/component are given, those should be used rather than overwriting them with the ones given on the command line. Or alternatively, behave the same way as we do when importing bugs (via importxml.pl), i.e. put the new bug report in moved-default-product and moved-default-component.

Comment 8

[Max Kanat-Alexander]

The use case of [e-mail] for filing bugs in the "Bugzilla" component is worthwhile.

Comment 9

[Corris]

Attachment: patch v1.2

Ok, how about explicitly setting the values on the argument list?  This way, one could set up different email addresses per-product, or even per-component if so inclined.  It also will use the value specified if it is using the @ variable.

Comment 10

[Corris]

Attachment: patch v1.3

I realized that the last patch will overwrite the product & component when replying to a bug that already exists.  this patch fixes that.

Comment 11

[Max Kanat-Alexander]

Comment on attachment 402843 [details] [diff] [review]
patch v1.3

  Instead of this, I'd like to be able to specify a file that contains defaults for every field.

  Sorry that I never got to this review--often, reviews that aren't specifically requested from a specific individual don't get done.

Comment 12

[Frédéric Buclin]

We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved.

I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else.

Comment 13

[Matthias Ludwig]

I’m trying to configure incomming E-Mails on my bugzilla-installation using email_in.pl. 
I’using Bugzilla 4.4  (No differences with 4.4.6 concerning email_in.pl)

To simplify the creation of bugs per E-Mail I use the parameter "--default" described in http://www.bugzilla.org/docs/4.0/en/html/api/email_in.html.
I configured default values fort he project and the component, operation system and hardware.

On creation of bugs this works fine.

The problem occurs when modifying a bug:
If someone wants to add a comment to an existing bug and does not provide the parametes (eg. @product, component@) the bug is moved to the default product/component. 


see comment 10
> I realized that the last patch will overwrite the product & component when replying to a bug that already
> exists.  this patch fixes that.

I did not catch what was planned für Release 4.4.
Is the beaviour I obvserved feature by design?
Or is there still a bug?
Does bugzilla provide other means to set the Defaults for product/component on bug creation?
see comment 11:
> Instead of this, I'd like to be able to specify a file that contains defaults for every field.

If not: my suggestion ist he following
Introduce a new parameter "--defaultoncreation"
This default values are only applied if a new bug is created. If both are set "--default" and "--defaultoncreation" either throw an error or define a priority handling (e.g.: --defaultoncreation defeats --default)