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)
Bugzilla
Incoming Email
Tracking
()
NEW
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
Comment 1•17 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.
Reporter | ||
Comment 2•17 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•17 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
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
Updated•17 years ago
|
Priority: P3 → P4
Updated•17 years ago
|
Component: Creating/Changing Bugs → Incoming Email
You need to log in
before you can comment on or make changes to this bug.
Description
•