284650 - Beginning a chart name with an "_" (underscore) causes errors

Status: RESOLVED FIXED

(Bugzilla :: Reporting/Charting, defect)

Description

[Justin C. De Vries]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040913 Firefox/0.10
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040913 Firefox/0.10

After creating a New Data Set for the New charting feature and returning to the
Create Chart page, the sub-category and name drop down lists are blank.

Reproducible: Always

Steps to Reproduce:
1. Select the "New Charting" feature from the Reporting and Charting Kitchen page
2. Select the "Create New Data Set"
3. Set up your query
4. In the Category select one of the options or create your own
5. In the Sub-Category select on of the options or create your own
6. In the Name enter "_somename" (first character is the underscore)
7. Click "Create Data Set"
8. Return to the New Charting feature

Actual Results:  
Once you have returned to the New Charting Feature you will notice that the
Sub-Category and Name fields are blank. 

Expected Results:  
Once you have retruned to the New Charting Feature you should see in the
Sub-Category and Name fields the name of the various previously created data
sets, including the data set that you just created.

I have been doing some extensive research and discovered the cause of this
behavior. It has to do with the "_" (underscore) character in the name that was
created. If you look in the 'javascript console' in the Firefox browser, you
will see a similiar error:

Error: syntax error
Source File: https://bugzilla.novell.com/chart.cgi
Line: 361, Column: 27
Source Code:  "_Underscore": , 

Error: catSelected is not defined
Source File: https://bugzilla.novell.com/chart.cgi
Line: 6892

It seems that this "_" is causing a javascript error that will not allow the
drop down lists to be populated correctly. The only solution that I have found
is to edit the name directly in the database to remove the "_" character from
the name.

Comment 1

[Gervase Markham [:gerv]]

I strongly suspect this is because TT treats hash keys beginning with an "_" or
"." as private:
http://www.stonehenge.com/merlyn/LinuxMag/col61.html
(search for "underscore", second reference).

Hmm. I wonder what other bits of Bugzilla we could break with judicious use of _
or . characters.

Gerv

Comment 2

[Frédéric Buclin]

This bug is annoying and still present. Two of our QA installations have a component name starting by "_", and I first thought all my data was deleted, till I realized it is simply hidden. We should find a workaround.

Comment 4

[Frédéric Buclin]

We now can disable private keys, thanks to $Template::Stash::PRIVATE = undef;

Comment 5

[Frédéric Buclin]

Attachment: patch, v1

Tested and works!

Comment 7

[Frédéric Buclin]

FYI, this parameter is available since TT 2.15.

Comment 8

[Frédéric Buclin]

(In reply to comment #7)
> FYI, this parameter is available since TT 2.15.

(... which is the minimal version of TT required in Bugzilla 3.2. Bugzilla 3.0 requires TT 2.12 only, and so this patch couldn't be applied there anyway.)

Comment 9

[Max Kanat-Alexander]

  I'm slightly wary about taking this for 3.4, I don't know if it will have other, unintended effects.

Comment 10

[Frédéric Buclin]

(In reply to comment #9)
>   I'm slightly wary about taking this for 3.4, I don't know if it will have
> other, unintended effects.

I doubt it has as we have a complete control on which hashes we use in templates. And as we are going to release 3.6 before 3.4.7, we would get feedback if something goes wrong. I'm not too worried about that.

Comment 11

[Frédéric Buclin]

Committing to: bzr+ssh://[e-mail]/bugzilla/trunk/
modified Bugzilla/Template.pm
Committed revision 7122.

Committing to: bzr+ssh://[e-mail]/bugzilla/3.6/
modified Bugzilla/Template.pm
Committed revision 7079.

Committing to: bzr+ssh://[e-mail]/bugzilla/3.4/
modified Bugzilla/Template.pm
Committed revision 6759.