291433 - Ability to have custom fields whose visibility depends on the values of other fields

Status: RESOLVED FIXED

(Bugzilla :: Bugzilla-General, enhancement, P1)

Description

[Max Kanat-Alexander]

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.

Comment 1

[Max Kanat-Alexander]

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

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

[Pascal Held]

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.

Comment 5

[Max Kanat-Alexander]

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

Comment 6

[Max Kanat-Alexander]

Attachment: Work In Progress

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.

Comment 7

[Max Kanat-Alexander]

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.

Comment 8

[Alex Eiser]

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.

Comment 9

[Max Kanat-Alexander]

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

Comment 10

[Max Kanat-Alexander]

Attachment: WIP 2

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

Comment 11

[Max Kanat-Alexander]

Attachment: v1

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 12

[Max Kanat-Alexander]

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.

Comment 13

[Max Kanat-Alexander]

Attachment: v2

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

Comment 14

[Max Kanat-Alexander]

Attachment: v3

Had to fix a few test failures.

Comment 15

[Max Kanat-Alexander]

Note to self: Have to add a visibilty_field_id_idx.

bbaetz: Any idea when you'll be able to review this?

Comment 16

[Bradley Baetz (:bbaetz)]

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 17

[Bradley Baetz (:bbaetz)]

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?

Comment 18

[Max Kanat-Alexander]

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

Comment 19

[Bradley Baetz (:bbaetz)]

(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

Comment 20

[Max Kanat-Alexander]

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.

Comment 21

[Max Kanat-Alexander]

Attachment: v5

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

Comment 22

[Bradley Baetz (:bbaetz)]

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.

Comment 23

[Max Kanat-Alexander]

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

Comment 24

[Max Kanat-Alexander]

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

Comment 25

[Max Kanat-Alexander]

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

Comment 26

[Frédéric Buclin]

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