I can imagine several situations in which people would like to have certain fields *appear* when other fields have a certain value, and certain fields *not* appear when certain fields have a certain value. For example, imagine that we had a field called "bug type," that said whether the bug was an "RFE" or a "Bug." For the "RFE" type of bug, you probably wouldn't want to have the "severity" field show up or be required. I wouldn't consider this to be *at all* part of the core functionality of custom fields, but instead a nice enhancement for the future.

*** Bug 75399 has been marked as a duplicate of this bug. ***

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".

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.

At the moment I implement sth. like this (see Bug #396974). In this feature a have also implement a function to define the visibility of a custom field, so you can show a field on every checkable condition.

NASA has actually funded me to work on this, so I will do it.

Here's what I have so far. I have the admin bits and the backend, but not the actual implementation for the client-facing pages.

There's one tricky bit about this feature. In past implementations I've done of this feature (for clients), when a field is hidden, its value doesn't change. The problem with this is that searches against the hidden field will still list the bug with the hidden field, if the hidden field matches. What would be ideal would be to be able to "unset" the field when it's hidden--that is, set it to NULL (which will never match anything). In that case, we'd also have to disable the field when it's hidden, so as not to send along a value for it. This means that for users without JS, the field would stay hidden and disabled until you submit the bug, and then it would appear again. This all will probably require some mucking around in the inner workings of Bugzilla::Bug, post_bug, and process_bug to make sure that things keep on working correctly once certain custom fields can be NULL.

One comment, You might want to add a field function which says "I have legal values" Its been something we have been kicking around for a while. Their are just so many places you need to use the following code ($field->type == FIELD_TYPE_SINGLE_SELECT || $field->type == FIELD_TYPE_MULTI_SELECT) That a field function which handles that kind of check would be helpful. Its a much more important to NASA, since we have all of the group fields as well.

Oh, sure, field.is_select would work, that's a good idea. :-)

Okay, here's a bit more work. I've decided not to do the disabling and nulling of the fields as part of this patch, as it was too complex (in fact, I might not do it at all).

Okay, this includes the administrative interface and the modifications needed to bug/field in order to show/hide fields. I also modified Bugzilla::Object->check to be able to take an id instead of just a name.

Comment on attachment 341657 [details] [diff] [review] v1 Oh, wait, this isn't ready yet--it doesn't work right when the controller is a multi-select.

Okay, this version works with multi-selects. :-) I now think that this is probably close to the "spiffiest" thing that Bugzilla does. :-D (Usually we're not very big on flashy stuff.)

Had to fix a few test failures.

Note to self: Have to add a visibilty_field_id_idx. bbaetz: Any idea when you'll be able to review this?

It looks fine, I just need to play with some of the edge cases. My repaired laptop will be arriving back today, so should be able to do these over the weekend.

Comment on attachment 341660 [details] [diff] [review] v3 A few issues: - If you set up the conditional (ie field_b only shows if field_a is set to 'foo'), theres nothing stopping you deleting 'foo' from being a value choice for field_a (no error, no FK constraints, etc). If you do this then go to edit field_b, it looks like its conditional on the first element, just because of the way that HTML select fields work - The behaviour when the field (or the field value) changes needs to be documented. - What if you wanted to have this show up in multiple states (even for a single multiple choice field)? - How does this all work when JS is disabled?

(In reply to comment #17) > (From update of attachment 341660 [details] [diff] [review]) > - If you set up the conditional (ie field_b only shows if field_a is set to > 'foo'), theres nothing stopping you deleting 'foo' from being a value choice > for field_a (no error, no FK constraints, etc). Ah, thanks. Yeah, that should be fixed. > - The behaviour when the field (or the field value) changes needs to be > documented. Documented? Eh? > - What if you wanted to have this show up in multiple states (even for a > single multiple choice field)? We don't support that yet. That would be a future enhancement. > - How does this all work when JS is disabled? Try it and see. It should work fine. Fields are shown until you submit, or hidden (and disabled, I believe) until you submit.

(In reply to comment #18) > > - The behaviour when the field (or the field value) changes needs to be > > documented. > > Documented? Eh? Well, what happens? It seems like the value is just hidden from the UI, but then it shows up in searches because its set in the db. This may be whats intended (sort of similar to flag inclusion/exclusions), but I can't tell :) > > - How does this all work when JS is disabled? > > Try it and see. It should work fine. Fields are shown until you submit, or > hidden (and disabled, I believe) until you submit. I did try :) Its a two stage process then, which is fine as long as we don't have the ability to have mandatory dependant fields, I guess. It also runs into the above problem when a custom field is no longer value

This feature will need documentation, and it will have to explain that if a field is hidden, bugs can still show up in searches for the field's value. You can see comment 7 and comment 10 for more details.

Okay, values are now not deletable if they control other fields.

Comment on attachment 344005 [details] [diff] [review] v5 r=bbaetz Theres nothing stopping mutually dependant requirements, but if someone sets that up I guess its there problem.

Yeah, the mutual-dependency thing might be a problem...we could possibly file a bug for that and fix it if necessary.

Checking in config.cgi; /cvsroot/mozilla/webtools/bugzilla/config.cgi,v <-- config.cgi new revision: 1.30; previous revision: 1.29 done Checking in editfields.cgi; /cvsroot/mozilla/webtools/bugzilla/editfields.cgi,v <-- editfields.cgi new revision: 1.10; previous revision: 1.9 done Checking in Bugzilla/DB.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/DB.pm,v <-- DB.pm new revision: 1.119; previous revision: 1.118 done Checking in Bugzilla/Field.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Field.pm,v <-- Field.pm new revision: 1.35; previous revision: 1.34 done Checking in Bugzilla/Object.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Object.pm,v <-- Object.pm new revision: 1.28; previous revision: 1.27 done Checking in Bugzilla/DB/Schema.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/DB/Schema.pm,v <-- Schema.pm new revision: 1.105; previous revision: 1.104 done Checking in Bugzilla/Field/Choice.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Field/Choice.pm,v <-- Choice.pm new revision: 1.6; previous revision: 1.5 done Checking in Bugzilla/Install/DB.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Install/DB.pm,v <-- DB.pm new revision: 1.57; previous revision: 1.56 done Checking in Bugzilla/WebService/Constants.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/WebService/Constants.pm,v <-- Constants.pm new revision: 1.20; previous revision: 1.19 done Checking in js/field.js; /cvsroot/mozilla/webtools/bugzilla/js/field.js,v <-- field.js new revision: 1.11; previous revision: 1.10 done Checking in js/util.js; /cvsroot/mozilla/webtools/bugzilla/js/util.js,v <-- util.js new revision: 1.5; previous revision: 1.4 done Checking in skins/standard/global.css; /cvsroot/mozilla/webtools/bugzilla/skins/standard/global.css,v <-- global.css new revision: 1.54; previous revision: 1.53 done RCS file: /cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/custom_fields/cf-js.js.tmpl,v done Checking in template/en/default/admin/custom_fields/cf-js.js.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/custom_fields/cf-js.js.tmpl,v <-- cf-js.js.tmpl initial revision: 1.1 done Checking in template/en/default/admin/custom_fields/create.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/custom_fields/create.html.tmpl,v <-- create.html.tmpl new revision: 1.10; previous revision: 1.9 done Checking in template/en/default/admin/custom_fields/edit.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/custom_fields/edit.html.tmpl,v <-- edit.html.tmpl new revision: 1.10; previous revision: 1.9 done Checking in template/en/default/admin/fieldvalues/confirm-delete.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/fieldvalues/confirm-delete.html.tmpl,v <-- confirm-delete.html.tmpl new revision: 1.12; previous revision: 1.11 done Checking in template/en/default/bug/field.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/field.html.tmpl,v <-- field.html.tmpl new revision: 1.19; previous revision: 1.18 done Checking in template/en/default/global/user-error.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/global/user-error.html.tmpl,v <-- user-error.html.tmpl new revision: 1.264; previous revision: 1.263 done

Added to the release notes for Bugzilla 3.4 in bug 494037.

Documentation added to bug 707170, Selenium script added to bug 308253.