User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16 From the query it appears that none of the values for the product are set and therefore it fails on columns which are supposed to be non-null. I entered the name and description, leaving other fields untouched. Reproducible: Always Steps to Reproduce: 1. Go to Administration 2. Click Products 3. Fill in Name and Description 4. Click Add Actual Results: Software error: DBD::mysql::db do failed: Column 'defaultmilestone' cannot be null [for Statement "INSERT INTO products (defaultmilestone, votesperuser, disallownew, name, classification_id, milestoneurl, maxvotesperbug, description, votestoconfirm) VALUES (?,?,?,?,?,?,?,?,?)"] at Bugzilla/Object.pm line 352 Bugzilla::Object::insert_create_data('Bugzilla::Product', 'HASH(0x17a31540)') called at Bugzilla/Product.pm line 106 Bugzilla::Product::create('Bugzilla::Product', 'HASH(0x18dcf9e0)') called at /PATH_TO/bugs/editproducts.cgi line 171 For help, please send mail to the webmaster (MY_EMAIL), giving this error message and the time and date of the error. Expected Results: New product was supposed to be created

I thought that undef would automatically trigger the default value for the DB column, but it doesn't. The column must not appear at all in the SQL call. Good to know! :)

Max, I know you prefer '---' to be stored in a constant, as suggested in bug 313122 comment 19, but the goal of this bug is to fix the crash. Yet another bug.

Comment on attachment 332527 [details] [diff] [review] patch, v1 Hmm, I'd rather rely on the DB default and not duplicate it in the code, in case somebody wants to customize it. You could have run_create_validators delete defaultmilestone if it's undef--I think that'd do it, no?

(In reply to comment #3) > Hmm, I'd rather rely on the DB default and not duplicate it in the code, in > case somebody wants to customize it. This problem can wait till the "Put --- in a constant" bug is fixed. > You could have run_create_validators delete defaultmilestone if it's undef--I > think that'd do it, no? Unless this is done in a central way in Object.pm, no. I don't want run_create_validators() in Project.pm to work differently. Probably Object->create() could drop undefined fields before creating the SQL to create the entry in the DB.

(In reply to comment #4) > I don't want run_create_validators() in Project.pm to work differently. Oh, I just meant specifically check for this field. You could also do it inside Product->create() > Probably > Object->create() could drop undefined fields before creating the SQL to create > the entry in the DB. No, we wouldn't do that, we want undef to mean explicitly NULL.

(In reply to comment #5) > Oh, I just meant specifically check for this field. You could also do it > inside Product->create() Hum, in this case, this behavior would apply to most fields in Product->create as I hardcoded most default values in validators.

(In reply to comment #6) > Hum, in this case, this behavior would apply to most fields in Product->create > as I hardcoded most default values in validators. Hmm...yeah, not certain what to do about that. Products are one of the few things that have meaningful defaults.

Comment on attachment 332527 [details] [diff] [review] patch, v1 Since this is a bug fix, I can go with this for now.

Checking in Bugzilla/Product.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Product.pm,v <-- Product.pm new revision: 1.29; previous revision: 1.28 done