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

RESOLVED FIXED in Bugzilla 3.4

Status

()

Bugzilla
Bugzilla-General
P1
enhancement
RESOLVED FIXED
13 years ago
6 years ago

People

(Reporter: Max Kanat-Alexander, Assigned: Max Kanat-Alexander)

Tracking

({selenium})

2.19.2
Bugzilla 3.4
selenium
Dependency tree / graph
Bug Flags:
approval +
documentation +
testcase +

Details

(Whiteboard: [Also relnote comment 11])

Attachments

(1 attachment, 5 obsolete attachments)

(Assignee)

Description

13 years ago
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.
(Assignee)

Updated

13 years ago
Target Milestone: --- → Bugzilla 2.24
(Assignee)

Updated

13 years ago
No longer depends on: 91037
(Assignee)

Comment 1

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

Comment 2

11 years ago
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
(Assignee)

Updated

10 years ago
Summary: Ability to have custom fields whose appearance depends on the values of other fields → Ability to have custom fields whose visibility depends on the values of other fields
(Assignee)

Updated

10 years ago
Priority: -- → P1
(Assignee)

Comment 3

10 years ago
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

Comment 4

10 years ago
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.
(Assignee)

Comment 5

9 years ago
NASA has actually funded me to work on this, so I will do it.
Assignee: general → mkanat
(Assignee)

Updated

9 years ago
Depends on: 357904
(Assignee)

Updated

9 years ago
Depends on: 456922
(Assignee)

Comment 6

9 years ago
Created attachment 340511 [details] [diff] [review]
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.
(Assignee)

Comment 7

9 years ago
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

9 years ago
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.
(Assignee)

Comment 9

9 years ago
Oh, sure, field.is_select would work, that's a good idea. :-)
(Assignee)

Comment 10

9 years ago
Created attachment 341585 [details] [diff] [review]
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).
Attachment #340511 - Attachment is obsolete: true
(Assignee)

Comment 11

9 years ago
Created attachment 341657 [details] [diff] [review]
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.
Attachment #341585 - Attachment is obsolete: true
Attachment #341657 - Flags: review?(bbaetz)
(Assignee)

Comment 12

9 years ago
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.
Attachment #341657 - Attachment is obsolete: true
Attachment #341657 - Flags: review?(bbaetz)
(Assignee)

Comment 13

9 years ago
Created attachment 341659 [details] [diff] [review]
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.)
Attachment #341659 - Flags: review?(bbaetz)
(Assignee)

Updated

9 years ago
Keywords: relnote
Whiteboard: [Also relnote comment 11]
(Assignee)

Updated

9 years ago
Blocks: 458436
(Assignee)

Comment 14

9 years ago
Created attachment 341660 [details] [diff] [review]
v3

Had to fix a few test failures.
Attachment #341659 - Attachment is obsolete: true
Attachment #341660 - Flags: review?(bbaetz)
Attachment #341659 - Flags: review?(bbaetz)
(Assignee)

Updated

9 years ago
Blocks: 459064
(Assignee)

Comment 15

9 years ago
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?
Attachment #341660 - Flags: review?(bbaetz) → review-
(Assignee)

Comment 18

9 years ago
(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
(Assignee)

Comment 20

9 years ago
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.
Flags: documentation?(documentation)
(Assignee)

Comment 21

9 years ago
Created attachment 344005 [details] [diff] [review]
v5

Okay, values are now not deletable if they control other fields.
Attachment #341660 - Attachment is obsolete: true
Attachment #344005 - Flags: review?(bbaetz)
Attachment #344005 - Flags: review?(bbaetz) → review+
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.
(Assignee)

Comment 23

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

Updated

9 years ago
Flags: approval+
(Assignee)

Comment 24

9 years ago
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
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Flags: testcase?
Resolution: --- → FIXED
Target Milestone: Bugzilla 4.0 → Bugzilla 3.4

Updated

9 years ago
Blocks: 471518

Updated

9 years ago
No longer blocks: 471518

Updated

9 years ago
Blocks: 471518
(Assignee)

Comment 25

9 years ago
Added to the release notes for Bugzilla 3.4 in bug 494037.
Keywords: relnote

Comment 26

6 years ago
Documentation added to bug 707170, Selenium script added to bug 308253.
Flags: testcase?
Flags: testcase+
Flags: documentation?
Flags: documentation+
Keywords: selenium
You need to log in before you can comment on or make changes to this bug.