197180 - Long component name accepted on component creation but not working when creating a bug

Status: RESOLVED FIXED

(Bugzilla :: Administration, task)

Description

[Carsten Lergenmüller]

User-Agent:       Mozilla/4.0 (compatible; MSIE 5.0; Windows 2000) Opera 6.03  [en]
Build Identifier: Bugzilla 2.16.2

We have a component with a very long name. It could be easily created. However, if we create bugs in that component, sanity check complains about a bad component entry. If we open the bug, it displays the wrong component (the first in the combobox, not the one with the long name). Re-setting the correct component does not help

Reproducible: Always

Steps to Reproduce:
1. On any product, create a component named 
WA-Clearing Behaelterzielermittlung realisieren (T 14.04 )
2. Create a bug for that component
3. Revisit bug -> wrong component entry
4. Run sanity check -> complaint about wrong component entry

Comment 1

[Bradley Baetz (:bbaetz)]

If you manually select bugs.product (via mysql), is the product name truncated?
the 2.16 limit is 64, and it is consistant in the bugs table and the components
table. That component name is < 64 chars anyway, so thats not it.

If you |SHOW CREATE TABLE bugs|, what is the datatype of the components field?
What about SHOW CREATE TABLE components| (the program field)

Comment 2

[Carsten Lergenmüller]

All our product names are complete in mysql.

The long-named component is cut, though:

mysql> select distinct bugs.component from bugs;
+----------------------------------------------------+
| component                                          |
+----------------------------------------------------+
(...)
| WA-Clearing Behaelterzielermittlung realisieren (T |
(...)


SHOW CREATE TABLE bugs:
(...)
 `component` varchar(50) NOT NULL default '',
(...)

(C.L.:) 50? Not 64?

SHOW CREATE TABLE components:
| components | CREATE TABLE `components` (
  `value` tinytext,
  `program` varchar(64) default NULL,
  `initialowner` mediumint(9) NOT NULL default '0',
  `initialqacontact` mediumint(9) NOT NULL default '0',
  `description` mediumtext NOT NULL
) TYPE=MyISAM |

Comment 3

[Jacob Steenhagen]

Quick and easy hack-type fix:
ALTER TABLE components CHANGE value value varchar(64);
ALTER TABLE bugs CHANGE component component varchar(64);

Note: This will set the limit to be 64 characters and make it the same for both
tables. You should be able to safely make them any size (up to 255, MySQL's limit)

This is no longer an issue in the latest devel. release as we now use
product/component ID's instead.

Comment 4

[Jacob Steenhagen]

Looks like we kept that little size discrepency right up until bug 43600 went in.

Comment 5

[Bradley Baetz (:bbaetz)]

Oh, I was looking at the product. Hmm. editcomponents never tests the value,
mind you.

For 2.16.3, we could:

a) Ignore this
b) Test in editproducts (50 here, 64 in 2.17)
c) Do an sql schema change

Thoughts?

Comment 6

[Gervase Markham [:gerv]]

Given that this guy is the first to hit it, I suggest we add

"(max 50 characters)"

and "maxlength='50'"

on the client side to the editcomponents.cgi page, and be done with it.

Gerv

Comment 7

[Bradley Baetz (:bbaetz)]

Attachment: 2.16 patch

I didn't change the descripton, just maxlength - it looks ugly in the <table>.

For the relnotes: 'Previous versions of bugzilla had different sizes for the
component name in various tables (bug 197180). For 2.16, the limit of 50
characters is now enforced. In releases later than (and including) 2.17.1, the
limit is 64 characters. This limit was implicitly enforced in that release,
although from 2.17.4 an error message will be generated instead of silently
truncating the name'

Or something like that.

A nicer patch needs this file to be rewritten. (Did you know that changing the
component name prints the message: 'Updated product name'? :)

Comment 8

[Bradley Baetz (:bbaetz)]

Attachment: 2.16 patch, take 2

I should test when adding, too....

Comment 9

[Bradley Baetz (:bbaetz)]

Attachment: patch for trunk

Comment 10

[Dave Miller [:justdave]]

did you mean to obsolete the 2.16 patch?

Comment 11

[Bradley Baetz (:bbaetz)]

Comment on attachment 117182 [details] [diff] [review]
2.16 patch, take 2

err, no :)

Comment 12

[Dave Miller [:justdave]]

approved for both branches

Comment 13

[Bradley Baetz (:bbaetz)]

Fixed in trunk and 2.16 branch.

Comment 14

[Bradley Baetz (:bbaetz)]

*** Bug 209153 has been marked as a duplicate of this bug. ***

Comment 15

[Dave Miller [:justdave]]

*** Bug 212472 has been marked as a duplicate of this bug. ***

Comment 16

[Dave Miller [:justdave]]

*** Bug 227988 has been marked as a duplicate of this bug. ***