Bug 1256246 - Obsolete custom fields with type of 'Integer' or 'Number' can not be deleted
Summary: Obsolete custom fields with type of 'Integer' or 'Number' can not be deleted
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Bugzilla
Classification: Community
Component: Administration
Version: 4.4
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: 4.4
Assignee: Matt Tyson 🤬
QA Contact: Rony Gong 🔥
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-08-24 07:18 UTC by yu zheng
Modified: 2018-12-09 06:29 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2015-09-17 02:48:45 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Mozilla Foundation 1198556 0 None None None Never

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.


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