When adding a component in editcomponents.cgi, it does not verify that the person you assign as the owner of that component has an account. (Bugzilla 2.9, cvs updated this afternoon)

I have since discovered that it adds an account for that person if they don't already have one, if you assign someone as an owner of a component. This is actually kind of cool, but in case you made a typo or something, it should probably prompt you to confirm you want to add an account for this person before actually doing it. "This person doesn't have a Bugzilla account yet. Create one for them?" or something like that.

tara@tequilarista.org is the new owner of Bugzilla and Bonsai. (For details, see my posting in netscape.public.mozilla.webtools, news://news.mozilla.org/38F5D90D.F40E8C1A%40geocast.com .)

Changing the summary of this bug to accurately reflect its current status. Still leaving it as a bug rather than an enhancement, as it has the potential to create unneeded users if you typo something.

ummm. wow. yeah. assigning to me to investigate.

>I have since discovered that it adds an account for that person if they don't >already have one, if you assign someone as an owner of a component. I don't see any SQL transactions regarding the profiles table, which is the primary table for accounts. Am I missing it? What this does do though, is allow you to create products and qa contact e-mail addresses even if these people do not yet have bugzilla accounts. code exists bug is commented out to do user verification. being able to create products and components before everyone gets an account is a fine and valid thing. so perhaps we should just put up warnings as you suggest. how we do that though is hard, since you won't know what the values are until submit time, which means another section of cgi that allows you to confirm or correct. or maybe if the user account doesn't exist, it just creates new users and does the new user e-mail.

Interesting........... OK. The components table has initialowner and initialqacontact as tinytext instead of mediumint, meaning that you can put whatever the heck you want in there. Of course, if you have an address that's not a valid user, the bug ends up without a QA Contact or owner when it is created, since the address won't resolve when it's looked up in the database. No mail is sent, since processmail bases everything on the userID's, and not the text email addresses (which it won't see anyway, since it's already translated to a userID by the time the bug is created) This also has the problem that if you change the person's email address in their user record, it'll no longer match the initialqacontact or initialowner for the product. I think this is a prime consideration for a schema change. The components table should use the userID's for these, if for no other reason that to allow you to change the user's email address without breaking it.

here's the code in globals.pl that would create the new user in this code. sub DBNameToIdAndCheck { my ($name, $forceok) = (@_); my $result = DBname_to_id($name); if ($result > 0) { return $result; } if ($forceok) { InsertNewUser($name, ""); $result = DBname_to_id($name); if ($result > 0) { return $result; } print "Yikes; couldn't create user $name. Please report problem to " . Param("maintainer") ."\n"; This is getting called with a 0 for $forceok now. I think the original report on this bug got fixed and no one closed this bug. Although digging through bonsai, I can't find any references to this being changed.... maybe something unrelated was broke just enough that it triggered it... But you're right, it does appear to be fixed now. Should we modify this to reflect the feature request to create an account for someone if they don't exist (and prompt before doing so?) or just go ahead and close this as fixed?

Lets fix this. (I'm not sure what part you think is fixed). No, it doesn't silently create a bogus account any more when you input an invalid login id, but now it has the potential to create bugs with invalid owners and qa contacts. I prefer the idea of changing the components table to use user profiles instead of strings. I tested this by changing the default owner of the bugzilla bugs to "tara@tequilarista.orgblah" (an invalid email). Bugzilla happily changed the default owner to this but did not create a new user with that name. If i had created a bug at this point, surely the owner would have been corrupted or bug creation would have failed. The reason I'd like the component editing page to require only valid bugzilla login id's is that every once in a while someone on our system will decide its a swell idea to have dual owners for a certain component and then type in "foo@foo.com, bar@bar.com" as the default owner, and bugzilla happily accepts this and it takes a while for anyone to notice that this is a mistake and in the mean time new bugs with invalid owners go unnoticed.

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

Changing summary to reflect the new direction this is going.

Okay, editcomponents.cgi now only accepts valid users for both initialowner and initialqacontact. I'm totally uninterested in automatic account creation as I think that's evil. I'm going to reset the summary on this to the original as that's the bug that I'm addressing, and opening a new bug to deal with the new schema aspect of this.

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

In the latest CVS version, it does in fact verify that the account exists when creating a new component. However, if you modify the component, you can still set it to a bogus address.

Is there a bug # for changing the assignee to a bogus address?

Tara, what's the bug # for the schema aspect of this?

OK, Tara's not here, does anyone know it?

Just posted a patch to change the initialowner and initialqacontact from tinytext to mediumint as bug #66876.

Sorry for the spam, but I needed to be able to query for all of these correctly.

Verified. This all goes smoothly now, especially with the userid changes.

Moving closed bugs to Bugzilla product