Hi all. A concept for a feature under BugId 359251

[Charlie Powell]

The retrieval of group information via ldap would be a nice idea, although a potential issue that could arrise there is discrepancies between various ldap infrastructures. (Please correct me if I'm wrong, as my ldap experience is very little and only just recent, but)... Can groups be defined in different means for different ldap servers, ie: M$'s AD vs. Zimbra's implementation? Either way, there would still need to be an internal mechanism, such as Bugzilla::Group, that provides the interface to the gui and logic. 




----- Original Message ----- 
From: "Gregary Hendricks" <ghendricks at novell.com> 
To: developers at bugzilla.org, dev-apps-bugzilla at lists.mozilla.org 
Sent: Thursday, July 9, 2009 4:58:08 PM GMT -05:00 US/Canada Eastern 
Subject: Re: Hi all. A concept for a feature under BugId 359251 

>>> On 7/9/2009 at 12:36 PM, in message <C67B86CA.2B22B%dmarshal at yahoo-inc.com>, 
David Marshall <dmarshal at yahoo-inc.com> wrote: 
> 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. 
> 

Adding my 2 cents: 

At Novell, we have implemented almost identical solutions in each of these cases, only we also have decentralized group membership management to allow product owners to enable external partners access to their products on an individual basis. 

There has been an internal request to allow Bugzilla to query ldap to be able to send email to an entire team. Since teams are managed in the corporate directory, and we don't want to create separate bugzilla groups for each possible team, it would be nice to be able to find out which teams own a product via a simple ldap query and then apply the emails to the CC of the bug. This way individuals can remove themselves from single bugs that do not concern them, where as with a group it is all or nothing. 

A request like this might not make sense in the vast majority of bugzilla installations, but for larger installations with large numbers of products, decrentralized product management is a must. I am generally in favor of anything that makes this possible. 

Greg 

- 
To view or change your list settings, click here: 
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=powellc@powelltechs.com> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20090709/3d01d934/attachment.html>