Hi all. A concept for a feature under BugId 359251

[David Marshall]

We have a similar capability at Yahoo!, although we do it rather differently
and, for the most part, externally.

I should first mention that we don't add users in the conventional way - we
manipulate the contents of table profiles with an external script that gets
input from another source.  New employees are automatically added as
Bugzilla users, and former colleagues are automatically disabled.
Additionally, we have a mailing list system from which we can get the set of
all active mailing lists.  We add these as pseudo-users.  No one logs in as
a mailing list, but users can add mailing lists as assignees, ccs, etc.

The biggest problem with this approach is because we only import the names
of mailing lists instead of who is on them, we are unable to determine
whether someone will be getting multiple emails about the same event.  I
myself usually get two copies of every event email.  It can be annoying!  We
add a lot of information to the email header so that those who are really
annoyed by it can create procmail recipes to weed out "duplicates."

The way that this applies to this discussion is that I would recommend
making Bugzilla::Group a subclass of Bugzilla::User, i.e. a group in some
contexts should be regarded as a special kind of user.  It might be
desirable to allow policy decisions about whether these "users" can be only
added as CC, perhaps, or can be given ownership of bugs.  At Y!, we employ
the concept of "product owner," so that we don't need to centrally manage
all 3500 products that we have.  We disallow mailing lists from becoming
product owners, for instance.


On 7/9/09 8:54 AM, "Leon KUKOVEC" <leon.kukovec at gmail.com> wrote:

> Hi,
> 
> My initial idea was to change the DB schema a bit in order to achieve
> the grouping as Charlie
> was suggesting. After a bit of thinking and seeing that we're already
> using e-mail lists in CC field at work - meaning the e-mail
> lists are already registered as login_names - I thought reusing
> that approach. As a result, a non standard, but doable idea came up
> which gives the flexibility to use e-mail list as a part of 'asignee',
> 'qa', or 'cc'
> and should not be that hard to do.
> 
> If we focus only on allowing 'BZ groups' in CC field
> I support the idea of going 'standard' way and am open to suggestions.
> 
> On Jul 9, 5:34 pm, Max Kanat-Alexander <mka... at bugzilla.org> wrote:
>> Guy Pyrzak wrote:
>>> One problem with that idea is that you kinda break the point of using a
>>> group and just turn it into a fast way to get a list of names. The
>>> primary use case you'd be breaking is someone new joining a group and
>>> then having no way to add them to all the bugs that the group is cc'ed on.
>> 
>>         Well, you could maybe have a group_cc table, and then when $bug->cc
>> is
>> called, expand the groups into users. We could then have $bug->cc_users
>> and $bug->cc_groups for the unexpanded versions.
>> 
>>         -Max
>> --http://www.everythingsolved.com/
>> Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
>> -
>> To view or change your list settings, click here:
>> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=dev-apps-bugzi...@lists.mozilla.o
>> rg>
> 
> _______________________________________________
> dev-apps-bugzilla mailing list
> dev-apps-bugzilla at lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-bugzilla
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=dmarshal@yahoo-inc.com>