Bug 1256246 - Obsolete custom fields with type of 'Integer' or 'Number' can not be deleted
Obsolete custom fields with type of 'Integer' or 'Number' can not be deleted
Product: Bugzilla
Classification: Community
Component: Administration (Show other bugs)
Unspecified Unspecified
medium Severity medium (vote)
: ---
: ---
Assigned To: Matt Tyson
Rony Gong
Depends On:
  Show dependency treegraph
Reported: 2015-08-24 03:18 EDT by yu zheng
Modified: 2015-09-16 22:48 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-09-16 22:48:45 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Mozilla Foundation 1198556 None None None Never

  None (edit)
Description yu zheng 2015-08-24 03:18:57 EDT
Description of problem:
Obsolete custom fields with type of 'Integer' or 'Number' can not be deleted.

Version-Release number of selected component (if applicable):

How reproducible:

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 19:22:31 EDT
This would be nice to fix, but is not a blocker for the hardware upgrade.
Comment 2 Matt Tyson 2015-08-25 21:00:22 EDT
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-16 22:48:45 EDT
This bug will be fixed in the linked upstream bug.

Note You need to log in before you can comment on or make changes to this bug.