Closed Bug 398557 Opened 17 years ago Closed 9 years ago

Allow custom free-text fields to be searched just like normal free-text fields on query.cgi

Categories

(Bugzilla :: Query/Bug List, enhancement, P1)

3.0.2
enhancement

Tracking

()

RESOLVED DUPLICATE of bug 342113

People

(Reporter: michael.j.tosh, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7
Build Identifier: 

We attempted to add all custom fields to the advanced search template for our installation.

We found that dropdown fields worked, but freetext fields didn't.

WORKS:  buglist.cgi?cf_dropdownname=legalvalue
DOESNT: buglist.cgi?cf_freetextname=text&cf_freetextname_type=allwordssubstr

What we noticed was that in Bugzilla/Search.pm, there is code to add all dropdowns and their legal values to the query string, but nothing to allow freetext fields.

    my @select_fields = Bugzilla->get_fields({ type => FIELD_TYPE_SINGLE_SELECT,
                                               obsolete => 0 });

Suggest that on line 402, you add custom freetext fields to this foreach loop:
foreach my $f ("short_desc", "long_desc", "bug_file_loc",
                   "status_whiteboard") {

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Actual Results:  
custom freetext field is ignored

Expected Results:  
custom freetext field should filter the results, without the URL overhead of using boolean searches.  (Many people are forced to use IE in the world, unfortunately.  Shouldn't just ignore them...)

I would expect that fields which are freetext get the same search options as the short_desc field.  They function the same, where the field could be a unique string for each issue.
Version: unspecified → 3.0.2
You can use boolean searches to query custom freetext fields, even if you don't like them (aka using IE, that's a separate issue). So I don't consider this as a bug, but a RFE to have them available outside boolean searches. Max, do we want to add them in the UI? This probably doesn't hurt.
Severity: major → enhancement
OS: Linux → All
This worked for me, adding it after the foreach at line 402:

    my @freetexts = Bugzilla->get_fields({ type => FIELD_TYPE_FREETEXT, 
                                           obsolete => 0 });
    foreach my $field (@freetexts) {
        my $f = $field->name;
        if (defined $params->param($f)) {
            my $s = trim($params->param($f));
            if ($s ne "") {
                my $type = $params->param($f . "_type");
                push(@specialchart, [$f, $type, $s]);
            }
        }
    }


Some people where I work, especially those who run the reports, don't understand boolean searches.  Too complicated I guess.
Here is the code added to template/en/custom/search/form.html.tmpl to show those fields in advanced search page:


<hr>

[%# *** Custom Drop-down Fields *** %]

<table>
  <tr>
    [% USE Bugzilla %]
    [% cf_fields = Bugzilla.get_fields({ obsolete => 0, custom => 1, type => constants.FIELD_TYPE_SINGLE_SELECT }) %]
    [% IF cf_fields %]
      [% count = 0 %]
      [% FOREACH field = cf_fields %]
        [% count = count + 1 %]
        <td>
          <table>
            <tr>
              <th align="left">
                <label for="[% field.name FILTER html %]" accesskey="a">[% field_descs.${field.name} %]</label>:
              </th>
            </tr>
            <tr valign="top">
              [% PROCESS cf_select sel = { field_obj => field, size => 7 } %]
            </tr>
          </table>
        </td>
        [% "</tr><tr>" IF (count % 5) == 0 %]
      [% END %]
    [% END %]
  </tr>
</table>

[%# *** Custom Free-text Fields *** %]

<table>
  <tr>
    [% cf_fields = Bugzilla.get_fields({ obsolete => 0, custom => 1, type => constants.FIELD_TYPE_FREETEXT }) %]
    [% IF cf_fields %]
      [% FOREACH field = cf_fields %]
        <tr>
          <th align="right">
            <label for="[% field.name %]" >[% field_descs.${field.name} %]</label>:
          </th>
          <td>
            <select name="[% field.name %]_type">
            [% FOREACH qv = query_variants %]
              [% type = "${field.name}_type" %]
              <option value="[% qv.value %]"
                [% " selected" IF default.$type.0 == qv.value %]>[% qv.description %]</option>
            [% END %]
            </select>
          </td>
          <td><input name="[% field.name %]" id="[% field.name %]" size="40"
                     value="[% default.${field.name}.0 FILTER html %]">
          </td>
          <td></td>
        </tr>
      [% END %]
    [% END %]
  </tr>
</table>

<hr>
oh, and this:


[%############################################################################%]
[%# Block for Custom SELECT fields                                           #%]
[%############################################################################%]

[% BLOCK cf_select %]
  <td align="left">
    <select name="[% sel.field_obj.name %]" id="[% sel.field_obj.name %]"
            multiple="multiple" size="[% sel.size %]">
      [% FOREACH name = sel.field_obj.legal_values %]
        <option value="[% name FILTER html %]">
        [% name FILTER html %]
        </option>
      [% END %]
    </select>
  </td>
[% END %]
ok, sorry to keep putting code in comments, BUT!...

In comment 4, I should have put this line inside the <option> block:
[% " selected" IF lsearch(default.${sel.field_obj.name}, name) != -1 %]


Also, in the PrefillForm {} sub, this foreach:
    my @cf_fields = Bugzilla::get_fields({ custom => 1, obsolete => 0 });
    foreach my $field (@cf_fields) {
        $default{$field->name} = [];
    }


Now it all works for me.
This should be a smaller part of the larger general task of allowing custom fields to show up as their own "boxes" on query.cgi.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Custom freetext fields not searched, where dropdowns are → Allow custom free-text fields to be searched just like normal free-text fields on query.cgi
Target Milestone: --- → Bugzilla 4.0
Priority: -- → P1
Depends on: 362436
(In reply to comment #6)
> This should be a smaller part of the larger general task of allowing custom
> fields to show up as their own "boxes" on query.cgi.

Which is bug 342113 ?
Depends on: 342113
(In reply to comment #7)
> Which is bug 342113 ?

  Yep!
(In reply to miketosh from comment #5)
> ok, sorry to keep putting code in comments, BUT!...
> 
> In comment 4, I should have put this line inside the <option> block:
> [% " selected" IF lsearch(default.${sel.field_obj.name}, name) != -1 %]
> 
> 
> Also, in the PrefillForm {} sub, this foreach:
>     my @cf_fields = Bugzilla::get_fields({ custom => 1, obsolete => 0 });
>     foreach my $field (@cf_fields) {
>         $default{$field->name} = [];
>     }
> 
> 
> Now it all works for me.

Hi, 
i am not sure where to place your code changes? I have changed:

<option value="[% name FILTER html %]">
        [% name FILTER html %]
        </option>


to 


<option value="[% name FILTER html %]">
[% " selected" IF lsearch(default.${sel.field_obj.name}, name) != -1 %]
        [% name FILTER html %]
        </option>

Is this the right way? Also i do not find any code that contains "prefill". Where must i paste that code change???

Regards

Manuel
We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved.

I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else.
Target Milestone: Bugzilla 4.4 → ---
Fixed in 6.0.
Status: NEW → RESOLVED
Closed: 9 years ago
No longer depends on: 342113
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.