50890 - Allow for multiple initialowner or initialqacontact instances per component

Status: RESOLVED WONTFIX

(Bugzilla :: Bugzilla-General, enhancement, P3)

Description

[Tara Hernandez]

This bug will likely expand to include more things, but we'll start here for 
now.

Reference http://bugzilla.mozilla.org/show_bug.cgi?id=24806 for some history.

Comment 1

[Chris Yeh]

i'm pretty sure this shouldn't be under consideration for 2.12, and the reason 
why is that the way intialowner and initialqacontact are stored in the database 
don't really allow for this. you'd need to minimally do a scehema change of some  
sort, or break this into another table. 

Comment 2

[Chris Yeh]

removing 2.12 designation, this is too big for 2.12

Comment 3

[Jacob Steenhagen]

I think this is best served by bug 38922 (which I almost have a patch for)...

Comment 4

[Matthew Tuck [:CodeMachine]]

I don't really agree.  We should probably have more security, so this bug makes
sense.  Also from a searching POV this is good.

Basically, there can be multiple assignees etc, so we should support it.

Comment 5

[Dave Miller [:justdave]]

Moving to real milestones...

Comment 6

[Hixie (not reading bugmail)]

Taking all Bugzilla 3.0 bugs -- congratulations to MattyT for the triage, it
really was spot on. Note: I may end up pushing some of these bugs back to 3.2,
we'll see. However, I believe all these bugs should just fall out of the 
redesign. Let's hope I'm right!

(Note: I'm also resetting the priority field to "---" so that I can retriage any
that I consider important or likely to be dropped.)

Comment 7

[Matthew Tuck [:CodeMachine]]

If you allow multiple people, does that mean no people are allowed?  It would be
a cleaner solution than [e-mail], for example because it wouldn't
appear on the output page as receiving a notification.

Of course, I would think that whether < 1 and > 1 are allowed should be prefs.

Comment 8

[Dave Miller [:justdave]]

The Bugzilla 3 component is going away.  We're going to depend on the Milestones 
for this.  At the time this component was created, we didn't have milestones for 
Bugzilla.

Comment 9

[Chris Yeh]

Oh dear. I actually have a need this now. What I'm suspecting is that this will 
require a component notifications table, and that gets referenced when we go do 
notifications.

I.E.

table: component_notify
componentid qa_contact eng_contact default
(mediumint) (mediumint) (mediumint) (yes/no or 0/1)

I know the table names are horrid. But you get the idea.

We'd also need a management page of some kind so that you can add and remove 
the extra people tacked onto the cc'list. So you would need to do four queries 
on the table to build the initial notification list:

select qa_contact from component_notify where default='Yes' and component=XX;
select eng_contact from component_notify where default='Yes' and component=XX;
select qa_contact from component_notify where default='No' and component=XX;
select eng_contact from component_notify where default='No' and component=XX;

Given that you'd only need to do this when you create a new bug, I don't think 
the overhead would be particularly bad. 

It kills me that the component table still doesn't have an index associated 
with it. But we all knew that.

I don't have any patches yet for this yet, but I wanted to run this by the 
powers that be (tm) if they had any particular favorite way they wanted me to 
implement this.

Comment 10

[Chris Yeh]

Okay, I figured out a clever way to do this that only involves added a column 
to the components table. It's a hack. It's worse than a hack. But it does 
squeeze into existing tablespace.

Create an index for all components.

Now insert the users you want to have watched by component, but for the watch 
column, use a negative number of which happens to be the index of a component. 
The watch column would have negative numbers that are indexes to the matching 
component. 

Comment 11

[Dave Miller [:justdave]]

Chris: see bug 76794

Comment 12

[Matthew Tuck [:CodeMachine]]

*** Bug 119554 has been marked as a duplicate of this bug. ***

Comment 13

[Hixie (not reading bugmail)]

Bailing on Bugzilla 3.0 due to too many other commitments.

Comment 14

[Frédéric Buclin]

*** Bug 277233 has been marked as a duplicate of this bug. ***

Comment 15

[Marc Schumann [:Wurblzap]]

*** Bug 289881 has been marked as a duplicate of this bug. ***

Comment 16

[Max Kanat-Alexander]

This isn't actually going to be implemented in Bugzilla 3.0.

This is best implemented as "ability to put a group anywhere you could put a user."

I thought I filed this, but I guess not...?

Comment 18

[Dave Miller [:justdave]]

Considering that Mozilla folks were driving this feature request and most of the bugs blocking this one have been WONTFIXed by Mozilla, I don't think this is going anywhere.