Hide editor presentations based on attribute values selected
I've searched around and I am not sure if this is possible.
I know that you can change what values are available in some of the presentations based on values. But I would like to say hide this presentation unless this X is selected. So for instance, I have an enumeration and I'd like a checkbox to display when 1 of the 5 values is selected. Is this possible in 3.0.1.1? |
3 answers
Millard Ellingsworth (2.5k●1●24●31)
| answered Feb 23 '12, 11:26 a.m.
FORUM ADMINISTRATOR / JAZZ DEVELOPER I've searched around and I am not sure if this is possible. I will find some time to play with this but it may not be today. Can you say some more about your intentions? When the checkbox is shown, I assume you want it to be editable? Is it okay if the form reflows on the change or do you just want it "covered up"? If the best we could do was change it from read-only to editable, would that suit your application? My first thoughts (in case you don't want to wait) are that you could do a Calculated Value Attribute Customization with an Attribute Dependency between your enumeration and the checkbox field. When the enumeration changes, you can manipulate the value (and maybe the visibility) of the checkbox field. I know the value change works. Will the editor hide and reveal it live? Only some experimentation will tell. |
Can you say some more about your intentions? For instance, we have an enumeration for the origin of a defect. So you can select whether it was found in a given phase of the development and test cycle. We would want to have something like if you select "System Test" as the value of the enumeration, then display a checkbox where you could choose to indicate whether you felt this defect was an escape or missed during a previous test phase or by development, etc. When the checkbox is shown, I assume you want it to be editable? Definitely. Is it okay if the form reflows on the change or do you just want it "covered up"? I am not sure I understand what you mean here. If the best we could do was change it from read-only to editable, would that suit your application? I suppose but it is less than ideal. I can easily see users asking why they can't edit the field. But if this is the only option, it may be ok. My first thoughts (in case you don't want to wait) are that you could do a Calculated Value Attribute Customization with an Attribute Dependency between your enumeration and the checkbox field. When the enumeration changes, you can manipulate the value (and maybe the visibility) of the checkbox field. I know the value change works. Will the editor hide and reveal it live? Only some experimentation will tell. I definitely don't want to manipulate the value of the checkbox field. If I could do this with visibility, I suppose this would solve our issue. Do you have a link handy for any articles or samples on how to do Calculated Value Attribute Customization so I can start looking at this in parallel? Thanks for the response and I hope my responses help. |
|
Millard Ellingsworth (2.5k●1●24●31)
| answered Feb 24 '12, 11:51 a.m.
FORUM ADMINISTRATOR / JAZZ DEVELOPER Do you have a link handy for any articles or samples on how to do Calculated Value Attribute Customization so I can start looking at this in parallel? Your responses do help. It sounds like there is one value of the enumeration for which you want this additional field to apply. So when the enumeration changes, you want to check the new value and either show (and make available for editing) this other field or hide it. As mentioned, I think the Calculated Value mechanism may make this possible as you can get your dependent attribute's script tickled when the driving attribute's value changes. A Condition Attribute Customization may also work just as well (it's just a mechanism for triggering a custom script). What I'm not certain of is whether visibility is something you can adjust during that processing. Another way might be to use a Dependent Enumeration where target set is only "Unassigned" for all choices except your special case. For your special case you can have 2 (or more) choices to reflect the submitter's position on the defect. This would let you map your extra data to more than one origin state or tailor it slightly for different origin states. And you don't have to write or deal with any custom scripting. This wiki article (requires login) should provide enough information to try either approach: https://jazz.net/wiki/bin/view/Main/AttributeCustomization#Script_based_calculated_values |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.