In an installation of Bugzilla some bugs may be reported not by the original customer, but by callcenter staff, project managers, account managers, or similar on behalf of the original customer. The original customer may or may not be able to access the Bugzilla installation herself. In our particular case, our Bugzilla installation is internal. It sits in our local, inside net, behind a firewall. Many of the bugs in the database are bugs found by our own developers and qa people. Yet, occasionally, a customer may also find a bug :-). We want to be able to put these bugs into the database, too. This leaves us with a conflict: We want to know who of our own staff entered the bug. In our case, that's likely to be an account manager. That's the person to ask questions. He should also get those emails when the bug gets resolved. So that person should be entered as the "reporter". On the other hand, we do sometimes prepare patches for individual customers. For this and other reasons, we want to be able to run queries from a particular customer's perspective. In our opinion, this would be best supported by a first class database field. (Of course, workarounds are possible: E.g., a string following a certain convention, to be entered in the "description" text of the bug. Or we could create one email account for each customer in our email system, and have those emails be forwarded to the account manager.) But the suggested enhancement is: An optional "original reporter" field should be added to a bug. That "original reporter" field could refer to a plain Bugzilla account. Additionally, certain people must be enabled to create and change Bugzilla accounts, even if they cannot access email that gets sent to the account. The preferences of any such account should be preset in a specific way. Typically, no emails should be automatically sent to such an account by Bugzilla.

This may be a good application for "generic custom fields", see bug 91037.

Thank you for the hint. I really like this custom field stuff and had already voted for bug 91037. But, for one thing, I'm running 2.14.1 here, and am not certain how much work it is to get all that running. I have not found a jumbo patch for 2.14.1 over at 91037. AMore importantly: Is there a way of saying "this custom field accepts a valid profiles.userid value"? Of course, I want the user to type in the profiles.login_name, which should be converted into a profiles.userid somewhere on the way to the database. It seems I'll have to try to roll my own. I'm a consultant, and I hope to be able to talk my customer into allowing me to publicly release whatever I come up with. You'll find it here. But by that time, I'm afraid template stuff will probably be out and nobody will be interested in a patch against 2.14.1 any more... :-(

I think custom fields is only for enumeration-type fields.

*** Bug 355130 has been marked as a duplicate of this bug. ***