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?
This is on Zippy's list, for purposes of tracking customer information.
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.
-> 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?
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.
> 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?
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.
> 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.
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.
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
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.
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.
(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.
(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.