Open Bug 388545 Opened 17 years ago Updated 11 years ago

Accept custom field names without "cf_" in email_in.pl

Categories

(Bugzilla :: Incoming Email, enhancement, P4)

enhancement

Tracking

()

People

(Reporter: altlist, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Build Identifier: 

If I create a new custom field, "foobar", email_in.pl requires I use "@cf_foobar" to set the value.

However, a user shouldn't have to determine if a field needs to a "cf_" prefix.

At the moment, I am scanning the fielddefs and make email_in.pl automatically add "cf_" if required.

Reproducible: Always
Not sure I like this idea. When using email_in.pl, you should know which fields exactly you are editing. Those are available from config.cgi anyway, so you know exactly how they are called. E.g., here is what my config.cgi returns about custom fields:

  { name:        'cf_reporter', 
    description: 'Original Reporter' },
  { name:        'cf_type', 
    description: 'Type' },

I'm suggesting WONTFIX.
As an administrator, I indeed know which fields are custom.  But I should not expect my customers to know which ones are custom or not, especially if this was for external use.  

Granted, even if the customer could run config.cgi, why would we want them to understand the internals of Bugzilla?  Ideally, you would like them to be comfortable using multiple bugzilla systems, without having to figure out differences in syntaxes.

For example, the team has talked about converting some builtin fields into custom fields, such as the status whiteboard.  That would mean a user would have to change from status_whiteboard to cf_status_whiteboard, but only for newer versions of bugzilla.  
It's not a WONTFIX, but it's not a high priority, and it's definitely something we'd have to consider. Fields are called cf_ on purpose so that they never conflict with built-in fields. I wouldn't like to add a built-in field in the future and then have everybody using the email interface get confused.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Summary: better handling of custom fields in email_in.pl → Accept custom field names without "cf_" in email_in.pl
Priority: P3 → P4
Component: Creating/Changing Bugs → Incoming Email
You need to log in before you can comment on or make changes to this bug.