Open Bug 359251 Opened 18 years ago Updated 13 years ago

Ability to put a group in any field that accepts a user

Categories

(Bugzilla :: Bugzilla-General, enhancement)

2.23.3
enhancement
Not set
normal

Tracking

()

People

(Reporter: mkanat, Unassigned)

References

Details

I thought I'd already filed this bug, but I guess not. Perhaps this is a dup of some bug with a strange summary, that I can't find.

You should be able to put a group in any field that accepts a user. This means QA, Assignee, and CC, right now. Reporter can't be edited, so it doesn't need to accept a group.

This would be possible by basically giving Bugzilla::User and Bugzilla::Group a similar interface for everything needed by a bug. Possibly we could even create a Bugzilla::Assignable that would be either a Group or User depending on the parameters passed in.
Whiteboard: [roadmap: 3.2]
Is this a dup of bug 306063?
Depends on: 306063
(In reply to comment #1)
> Is this a dup of bug 306063?

  No, this has a broader scope.
Dupe of bug 51099?
If you change the word alias to group, then yes 51099 sounds the same.
(In reply to comment #3)
> Dupe of bug 51099?

  Not totally. He's asking for two things--aliases and then this bug. This bug also has a more focused, clearer description. If anything, you could dup that bug to this one, as this implements the more important part of that bug.
I think this would be a really nice feature! 
Currently, we use mail aliases a lot in our organization to easily CC for example "service" departement on issues. Though this works pretty well, the system does not recognize that user "A" (for example assignee) may be part of "service" alias, too. Therefore "A" getting lots of duplicate notification emails and complaining about that...

(Or is there another workaround to prevent such alias-duplicates from within bugzilla?)
 
Also voting on this issue.
Would really like to see it in the next major release.
Whiteboard: [roadmap: 3.2]
Adding my vote.

I'm thinking about investing some time into this patch - if the
general opinion is that this is something beneficial. 

From the development point of view (correct me if I'm wrong), this
would mean maintaining group-table with id's of users and when
whining or sending e-mail due to update, Bugzilla would need to 
breakdown CC list and resolve groups and filter duplicate ids.

A group format in CC/QA would need to have different format than e-mail
to make sure people can't reassign a bug to a group or so.
I am a newbie on perl but willing to take the challenge and work on this bug, as this feature is required in our workplace.

What is expected of this bug?
What are the requirements from Bugzilla team?
For the record, I found a cheap way to support this by using an external mailing list and manage the mailing list outside of Bugzilla.  The one downside was that if a user was CC'd individually and the mailing list the person is on is also CC'd, he would get two email messages.

I resolved the duplicate email by maintaining a bz_mailing_list table (list_id, userid) that listed who was on which mailing list.  Then in BugMail.pm, I auto-expanded the recipient based on the mailing list table.  

+    # Now expand the recipients using the bz_mailing_lists table
+    foreach my $list_id (keys %recipients) {
+      my $members =
+          $dbh->selectcol_arrayref("SELECT member_id FROM bz_mailing_lists
+                                    WHERE list_id=$list_id", undef, ());
+      if (scalar(@$members)) {
+        foreach my $member (@$members) {
+          $recipients{$member} = $recipients{$list_id};
+        }
+        delete $recipients{$list_id};
+      }
+    }
+

Granted, a UI would be needed to manage the mailing list.  For me, given that mailing lists at my company is managed in LDAP, I created a crontab job to auto-synced the LDAP mailing list info with Bugzilla.  

While the ldap sync may be too custom to be of use, the mailing list approach could be a cheap way to address the need.
Hey Albert. If you're using some standard mailing list solution like mailman (or simply have lists in LDAP) I bet this would make an awesome generic extension that people would love to have.
You need to log in before you can comment on or make changes to this bug.