The make_options sub improperly uses regular expressions wrt default values

RESOLVED FIXED in Bugzilla 2.18



17 years ago
6 years ago


(Reporter: dan, Assigned: endico)


Bugzilla 2.18



(1 attachment)



17 years ago
In several places, the make_options sub found in is used to create an 
HTML element from a list of options and the default option(s) to set as 
SELECTED.   If it's a single-select set of options, all is well.   If it's a 
multi select, the default value is submitted as "val1|val2|val3..." and used as 
a regular expression.

This produces incorrect results.  First of all, the "^" and "$" would have to 
be used to match the entire expression.  Here is a snippet that proves it:
@items = ('Foo', 'Foo Two', 'Bar', 'Bar Two', 'Baz', 'Baz Two');
$default = 'Foo|Bar';
 If the $default is matched to @items as a regular expression, 4 of them match
successfully even though only two options should be matched.

This same argument is true if the default values can contain any characters 
that would be interpreted as meta-characters in regular expressions.

In short, it's not valid to consider pipe-delimited values to be valid "or'd" 
regular expressions.   Rather, the code should split on '|' and compare the 
values with the 'eq' operator.

I'll attach a diff file that demonstrates how I solved this issue after I 
submit the bug.

Comment 1

17 years ago
This is how I solved the problem in make_options().  Sorry it's not a true diff
file - my base code has already been modified.
Moving to 2.18 but make_options is probably going away as it probably has no
place in the templatised world.
Priority: -- → P3
Target Milestone: --- → Bugzilla 2.18
This is fixed, in that make_options no longer exists. There was only one use in
2.16 (for reporting), and that has been removed in current cvs
Last Resolved: 16 years ago
Resolution: --- → FIXED
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.