If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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




Incoming Email
10 years ago
4 years ago


(Reporter: Albert Ting, Unassigned)





10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20070515 Firefox/
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

Comment 1

10 years ago
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.

Comment 2

10 years ago
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.  

Comment 3

10 years ago
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
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


10 years ago
Priority: P3 → P4


10 years ago
Component: Creating/Changing Bugs → Incoming Email
You need to log in before you can comment on or make changes to this bug.