136834 - Additional field "original reporter" for, e.g., callcenter use.

Status: RESOLVED DUPLICATE of bug 287332

(Bugzilla :: User Accounts, enhancement, P3)

Description

[Andreas Krüger]

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.

Comment 1

[Andreas Franke (gone)]

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

Comment 2

[Andreas Krüger]

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...  :-(

Comment 3

[Matthew Tuck [:CodeMachine]]

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

Comment 4

[victory <[e-mail]>]

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