Description of problem: Obsolete custom fields with type of 'Integer' or 'Number' can not be deleted. Version-Release number of selected component (if applicable): 4.4.9039-3 How reproducible: 100% Steps to Reproduce: 1. Create two fields through Administration -> Custom Fields -> Add a new custom field. Details is as below: Name: cf_test1, Type: Integer Name: cf_test2, Type: Number Both have 'Can be set on bug creation' and 'Displayed in bugmail for new bugs' checked and 'product is TCMS' set for 'Field only appears when'. 2. Modify two fields with 'Is obsolete' checked. 3. Go back to custom field list page, click 'Delete' and confirm the deletion. Actual results: DBD::Pg::db selectrow_array failed: ERROR: invalid input syntax for integer: "" LINE 1: ...T(*) FROM bugs WHERE cf_test1 IS NOT NULL AND cf_test1 != '' ^ [for Statement "SELECT COUNT(*) FROM bugs WHERE cf_test1 IS NOT NULL AND cf_test1 != ''"] at /var/www/html/bugzilla/Bugzilla/Field.pm line 983 Bugzilla::Field::remove_from_db('Bugzilla::Field=HASH(0x7f12ef4a4118)') called at /var/www/html/bugzilla/editfields.cgi line 156 ModPerl::ROOT::Bugzilla::ModPerl::ResponseHandler::var_www_html_bugzilla_editfields_2ecgi::handler('Apache2::RequestRec=SCALAR(0x7f12f03f2570)') called at /usr/lib64/perl5/vendor_perl/ModPerl/RegistryCooker.pm line 204 eval {...} called at /usr/lib64/perl5/vendor_perl/ModPerl/RegistryCooker.pm line 204 ModPerl::RegistryCooker::run('Bugzilla::ModPerl::ResponseHandler=HASH(0x7f12efb2dda0)') called at /usr/lib64/perl5/vendor_perl/ModPerl/RegistryCooker.pm line 170 ModPerl::RegistryCooker::default_handler('Bugzilla::ModPerl::ResponseHandler=HASH(0x7f12efb2dda0)') called at /usr/lib64/perl5/vendor_perl/ModPerl/Registry.pm line 31 ModPerl::Registry::handler('Bugzilla::ModPerl::ResponseHandler', 'Apache2::RequestRec=SCALAR(0x7f12f03f2570)') called at /var/www/html/bugzilla/mod_perl.pl line 134 Bugzilla::ModPerl::ResponseHandler::handler('Bugzilla::ModPerl::ResponseHandler', 'Apache2::RequestRec=SCALAR(0x7f12f03f2570)') called at -e line 0 eval {...} called at -e line 0 Expected results: Fields should be deleted successfully.
This would be nice to fix, but is not a blocker for the hardware upgrade.
This also breaks on upstream when using postgres. Works fine on MySQL. When the field is created it's created as 'NOT NULL DEFAULT 0' which seems odd. I would expect it just to be DEFAULT NULL and to have it come up as blank on the show_bug page.
This bug will be fixed in the linked upstream bug.