342113 - Allow custom fields to appear as a discrete field in the search form

Status: RESOLVED FIXED

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

Description

[Myk Melez [:myk] [@mykmelez]]

Custom fields are listed in the Fields drop-down menu of the boolean charts, but they don't appear as a discrete field in the search form, as other fields do.  They should appear there as well.

Comment 1

[P P N]

I am new to bugzilla and hence would require some help from you all here.

Could anyone let me know if these enhancements on custom field has been completed? If yes, how to get the current updates / patches for bugzilla 2.20? In such a case will all the new customization [custom field] etc get merged with bugzilla 2.20 release?

The customizations mentioned here would really come handy for us too. Please
check BUG #344086 about the same. Looking forward to your replies on the same.

Thanks,

Comment 2

[Frédéric Buclin]

This bug is retargetted to Bugzilla 3.2 for one of the following reasons:

- it has no assignee (except the default one)
- we don't expect someone to fix it in the next two weeks (i.e. before we freeze the trunk to prepare Bugzilla 3.0 RC1)
- it's not a blocker

If you are working on this bug and you think you will be able to submit a patch in the next two weeks, retarget this bug to 3.0.

If this bug is something you would like to see implemented in 3.0 but you are not a developer or you don't think you will be able to fix this bug yourself in the next two weeks, please *do not* retarget this bug.

If you think this bug should absolutely be fixed before we release 3.0, either ask on IRC or use the "blocking3.0 flag".

Comment 3

[Max Kanat-Alexander]

Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set the "blocking3.2" flag to "?", and either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.

Comment 4

[Frédéric Buclin]

We should add a new checkbox in editfields.cgi "Have its own field in the Search page" or something like that. This would be especially useful for single-select and multi-select fields.

Comment 5

[Max Kanat-Alexander]

Yes, I have code for this internally at Everything Solved. I can post it if anybody wants to see if before starting work.

Comment 6

[miketosh]

If you have code already, why not submit it via this bug to get it fixed?  (Assigned To:  	 Nobody; OK to take it and work on it)

If you have most of the code and it just needs a little touch up for 3.1.x-latest, post it and I'll dig into it.

Comment 8

[Todd]

You can add all free text fields, by inserting [% PROCESS cf_freetext %] right after "<!-- Good place for Free Text fields -->" into /template/en/custom/search/form.html.tmpl

However support for other field types is marked as "NOT WORKING ... NOT USED." I would personally love to be able to add a "Drop Down" custom field to my advanced search page. 

Max ... could you post that code?

Comment 9

[Todd]

Ooops! Sorry for the distraction!

Adding [% PROCESS cf_freetext %] is not effective. The search fields appear in the user interface, but they don't function properly.

Comment 10

[Rob Siklos [:robzilla]]

Todd:

In 3.2.x, it's easy to add support for a dropdown, but you have to modify query.cgi in two places.  For instance, I added a dropdown-type custom field called "Issue Type" (cf_issuetype).  So I changed query.cgi as follows:

1) In the PrefillForm subroutine, there's a big foreach near the top which starts like 'foreach my $name ("bug_status", "resolution"...)'.  I added "cf_issuetype" to the list of fields named there.

2) around line 262, you'll find a line which looks like this:
    $vars->{'bug_severity'} = get_legal_field_values('bug_severity');
All you have to do is add one for your custom field below it:
    $vars->{'cf_issuetype'} = get_legal_field_values('cf_issuetype');


Then, in the form.html.tmpl, you just do something like this:

  [% PROCESS select sel = { name => 'cf_issuetype', size => 7 } %]

Comment 11

[Todd]

Rob, your clues in comment #10 worked great, thanks.

Comment 12

[Albert Ting]

Attachment: v1

Attached is a suggested patch based on the 3.4.4 code base.

This only addresses select fields for now.

Comment 13

[Frédéric Buclin]

Comment on attachment 420099 [details] [diff] [review]
v1

r- per comment 4 and per my discussion with mkanat on IRC.

Comment 14

[Bent Foyn]

We have tried your suggested solutions.
1. The solution from comment 8 gives a fatal error on query.cgi
2. The solution from comment 12/13 generated another fatal error

We should probably aim for another solution ...

Comment 16

[Bill Barry]

This bug probably isn't the best place for this but I don't know of any better and don't feel like entering a whole new bug on my own for something I have no intention of providing a patch for at this time:

It could be really easy to add a custom field to the search page via an extension (easy enough that it could be an example extension), if only there was a hook available from query.cgi.

Say around line 348 (against 4.0.3 codebase, a line like this would be the only patch necessary; an example extension and a blog post tutorial would be a sweet bonus but unnecessary):
Bugzilla::Hook::process('query_defaultvars', { vars => $vars });

then you could define the hook in your extension (something like this):
NAME/Extension.pm
--------
use strict;
use lib qw(. lib);

use Bugzilla;
use Bugzilla::Field;

sub query_defaultvars {
    my ($self, $args) = @_;
    
    my $vars = $args->{vars};
    $vars->{'cf_type'} = Bugzilla::Field->new({name => 'cf_type'})->legal_values;
}

NAME/template/en/default/hook/search/form-after_selects_top.html.tmpl:
--------
[% INCLUDE "search/field.html.tmpl" 
      field => bug_fields.cf_type
      accesskey => "t" 
      value => default.cf_type
%]


(warning: untested code typed in bugzilla comment area)

Comment 17

[Frédéric Buclin]

I'm pretty sure this is easily doable now.

Comment 18

[Frédéric Buclin]

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.

Comment 19

[Joel Maher ( :jmaher ) (UTC -8)]

:dylan, is this bug still a useful bug to have?  If so, can we get a mentor assigned?

Comment 20

[Albert Ting]

Attachment: v2

For what it's worth, I'm using this patch to include all custom select and text fields.  This has been more than sufficient for my company.  Recommend creating separate tickets to make this settable on a per field basis.

Comment 21

[:glob ✱]

Comment on attachment 8576856 [details] [diff] [review]
v2

Review of attachment 8576856 [details] [diff] [review]:
-----------------------------------------------------------------

r=glob

this looks great, thanks!

::: template/en/default/search/form.html.tmpl.orig
@@ +221,5 @@
>      %]               
> +    [% FOREACH field = custom_fields %]
> +      [% IF field.type == constants.FIELD_TYPE_SINGLE_SELECT or
> +         field.type == constants.FIELD_TYPE_MULTI_SELECT %]
> +        [% INCLUDE "search/field.html.tmpl" 

trailing whitespace; will fix on commit.

Comment 22

[:glob ✱]

To ssh://[e-mail]/bugzilla/bugzilla.git
   0f01ca1..42584a8  master -> master