175272 - Contacts Related to Bug

Status: RESOLVED WONTFIX

(Bugzilla :: Bugzilla-General, enhancement)

Description

[Jeff Hedlund]

This may be a niche feature request, but perhaps other people would find it useful.

I use Bugzilla for tracking many issues, not just software related issues.  I
would find it useful to have a list of contacts that are "connected" to a bug. 
This would be similar to the CC list, except that the people would not be
emailed and the people would not [necessarily] be users in Bugzilla.

I'm envisioning that it could grab vital data from LDAP, like phone, company,
whatever.  

I don't think this would work well under the custom fields patch, since it would
have to be integrated more tightly (for example, the LDAP lookup). 

This would be helpful since it would list the contact information for a
particular person right there on the bug.  Searching by contacts would be useful
as well.

Comments?

Comment 1

[Dave Miller [:justdave]]

This is on Zippy's list, for purposes of tracking customer information.

Comment 2

[Jeff Hedlund]

Ideas:  

  A CC-type list that can include users, or non-users
  Ability to search on this Contact list
  A checkbox that allows the current comment to be mailed to selected Contacts
    If comment emailed to select contacts, it should note that on the comment
    
As far as the e-mailing to contacts goes:

When e-mailing people on the contact list, should there be an option to send
individual email or CC them on a single email?

There would be times when you wouldn't want other contacts to see who
else is getting the e-mail (sales inquires sent to multiple vendors, etc).  But
there may be times when you want the recipients to be able to reply-all (regular
discussion type e-mail).

Could have a dropdown like this:
  [ ] Send [Individual / CC|] E-mail to Selected Contacts

Or maybe no checkbox, just a drop down:
  Send [ No / Individual / CC] E-mail to Selected Contacts

The From: should be from the user entering the comment.

Also a user-pref for signature sent with "Contact" e-mails would be nice.

Comment 3

[Jeff Hedlund]

-> Taking

Additional Design Ideas:

Make a new table in the DB for these contacts.  They can automatically be added
to that table upon adding the e-mail address in the contact field, and [later?]
have more details associated with them such as company name, phone number, etc.

Maybe later it could be expanded to use LDAP instead of a table in the DB.

Comments on these?

Comment 4

[Dave Miller [:justdave]]

New table seems to be the way to go.

Only thing I wonder about is if someone who has an account becomes a customer.
:)  profiles and customers would have duplicates?  Though I suppose it wouldn't
hurt anything.

Comment 5

[Jeff Hedlund]

> Only thing I wonder about is if someone who has an account becomes a customer.
> :)  profiles and customers would have duplicates?  Though I suppose it wouldn't
> hurt anything.

Yeah, I thought about that too.

Maybe storing the contact e-mail in the profile table with a flag specifying
that profile is not a user (similar to disabled text).  Then if the user creates
an account, it just changes that flag.

There could still be a new table that links with the profiles table to provide
the more detailed information (plus this would allow more information for user
profiles as well).

Is there any downside to doing it that way?

Comment 6

[Bradley Baetz (:bbaetz)]

Why can't these 'contacts' be users? Its not like we have a limit on how many
users we can have.

you could set disabledtext on them if you didn't want them to be able to log in.

Comment 7

[Jeff Hedlund]

> Why can't these 'contacts' be users? Its not like we have a limit on how many
> users we can have.
> you could set disabledtext on them if you didn't want them to be able to log in.

That's basically what I was saying.  I suggested using another field so that
Bugzilla would be able to distinguish between a disabled account and a "never
created" account.  But we could automatically set a disabledtext to a constant
value so that if they create an account, Bugzilla would know to remove the
disabledtext.

Comment 8

[Dave Miller [:justdave]]

We should add a boolean value in the profiles table for disabled.  Or even make
it an integer with an "account class", 0=disabled, 1=real user, 2=customer info
record, or something like that.

While the disabledtext being null thing makes it easy for the machine to read
and saves space in the database, it's a major hack when it comes to UI, and it
causes problems when someone accidently puts a space in the field in editusers, etc.

Comment 9

[Gervase Markham [:gerv]]

IMO, the best way to implement the "contacts" part of this is to have a single
additional field in the profiles table, which is a URL. On installations like
b.m.o, this can be configured to point to the person's web site. On
installations which require contacts functionality, it can point to the web
interface of the external application which stores this information.

I think we should do our best to avoid Bugzilla becoming an address book :-)
People who are involved but shouldn't be sent mail can be CCed, and mail
disabled for them (and perhaps the account too.)

Gerv

Comment 10

[Jeff Hedlund]

The URL idea could maybe work for me... Another idea I had to get more
information about a certain contact in the list would be to have a button to for
more information that pops up a window to show more info (phone, address, etc).
 This could be made to work with the URL idea, just passing the email address in
the URL.  This keeps the bug screen cleaner (just shows e-mail addresses) but
allows detailed information convenient.

> People who are involved but shouldn't be sent mail can be CCed, and mail
> disabled for them (and perhaps the account too.)

I think a seperate box would be more appropriate, since they are not CC'd. 
Plus, I'd like to have the option of actually mailing a comment to >=1 people in
that list at certain time.  This would also allow putting actual users in this
"Related Contacts" box that would not be e-mailed (or have access to the bug).

And definitely the account should be disabled until created by the user.

Comment 11

[cb13]

In addition to the searching by contact, it would be a great feature to do
queries by company (the contact persons belong to). Than you can provide
information on all bugs associated to a whole company, not only to single persons.

Comment 12

[Bill Barry]

(In reply to comment #11)
> In addition to the searching by contact, it would be a great feature to do
> queries by company (the contact persons belong to). Than you can provide
> information on all bugs associated to a whole company, not only to single persons.

This would be a an awesome addition. On our installation we use groups to denote what company (or client) or companies that a bug belongs to. I have made multiple template customizations to make this a little easier to understand, but it feels like it cripples the abilities to use groups effectively.

Is anything happenning to this? The last comment was almost 2.5 years ago.

Comment 13

[Frédéric Buclin]

(In reply to Jeff Hedlund from comment #0)
> This may be a niche feature request, but perhaps other people would find it
> useful.

This really looks a niche case and we don't plan to support this in the core code -> wontfix.