Closed Bug 342113 Opened 15 years ago Closed 6 years ago

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

Categories

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

2.23
enhancement

Tracking

()

RESOLVED FIXED
Bugzilla 6.0

People

(Reporter: myk, Assigned: altlist)

References

Details

(Keywords: relnote)

Attachments

(1 file, 1 obsolete file)

v2
1.80 KB, patch
glob
: review+
Details | Diff | Splinter Review
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.
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,
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".
Target Milestone: Bugzilla 3.0 → Bugzilla 3.2
Blocks: 398557
Severity: normal → enhancement
Priority: -- → P1
Summary: custom fields don't appear as a discrete field in the search form → Allow custom fields to appear as a discrete field in the search form
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.
Target Milestone: Bugzilla 3.2 → Bugzilla 4.0
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.
Whiteboard: [roadmap: 4.0]
Yes, I have code for this internally at Everything Solved. I can post it if anybody wants to see if before starting work.
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.
Duplicate of this bug: 456359
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?
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.
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 } %]
Rob, your clues in comment #10 worked great, thanks.
Keywords: student-project
Whiteboard: [roadmap: 4.0] → [roadmap: 4.0][3.6 Focus]
Attached patch v1 (obsolete) — Splinter Review
Attached is a suggested patch based on the 3.4.4 code base.

This only addresses select fields for now.
Attachment #420099 - Flags: review?(LpSolit)
Comment on attachment 420099 [details] [diff] [review]
v1

r- per comment 4 and per my discussion with mkanat on IRC.
Attachment #420099 - Flags: review?(LpSolit) → review-
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 ...
Duplicate of this bug: 714089
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)
I'm pretty sure this is easily doable now.
Assignee: general → query-and-buglist
Component: Bugzilla-General → Query/Bug List
Whiteboard: [roadmap: 4.0][3.6 Focus] → [roadmap: 4.0][3.6 Focus][Good Intro Bug]
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 → ---
Whiteboard: [roadmap: 4.0][3.6 Focus][Good Intro Bug] → [roadmap: 4.0][3.6 Focus][good first bug][lang=perl]
Whiteboard: [roadmap: 4.0][3.6 Focus][good first bug][lang=perl] → [good first bug][lang=perl]
:dylan, is this bug still a useful bug to have?  If so, can we get a mentor assigned?
Flags: needinfo?(dylan)
No longer blocks: 1126453
Attached patch v2Splinter Review
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.
Attachment #420099 - Attachment is obsolete: true
Attachment #8576856 - Flags: review?(glob)
Flags: needinfo?(dylan)
Assignee: query-and-buglist → altlist
Keywords: student-project
Whiteboard: [good first bug][lang=perl]
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.
Attachment #8576856 - Flags: review?(glob) → review+
To ssh://gitolite3@git.mozilla.org/bugzilla/bugzilla.git
   0f01ca1..42584a8  master -> master
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: approval+
Keywords: relnote
Resolution: --- → FIXED
Target Milestone: --- → Bugzilla 6.0
No longer blocks: 398557
Duplicate of this bug: 398557
See Also: → 1568592
You need to log in before you can comment on or make changes to this bug.