Bug 1256246

Summary: Obsolete custom fields with type of 'Integer' or 'Number' can not be deleted
Product: [Community] Bugzilla Reporter: yu zheng <yuzheng>
Component: AdministrationAssignee: Matt Tyson 🤬 <mtyson>
Status: CLOSED UPSTREAM QA Contact: Rony Gong 🔥 <qgong>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.4CC: jmcdonal, mtahir, mtyson, qgong
Target Milestone: 4.4   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-09-17 02:48:45 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description yu zheng 2015-08-24 07:18:57 UTC
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.

Comment 1 Jason McDonald 2015-08-24 23:22:31 UTC
This would be nice to fix, but is not a blocker for the hardware upgrade.

Comment 2 Matt Tyson 🤬 2015-08-26 01:00:22 UTC
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.

Comment 3 Matt Tyson 🤬 2015-09-17 02:48:45 UTC
This bug will be fixed in the linked upstream bug.