Dynamic Resolutons
![]() Is there a way to hide or show a resolution code based on the value of another attribute? We would like to make a resolution code available only when one of our custom attributes has a certain value.
Thanks, Rod |
3 answers
![]()
Ralph Schoon (62.3k●3●36●43)
| answered Jan 23 '13, 11:18 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER edited Jan 23 '13, 2:19 p.m.
Hi Rod,
Resolutions is a small string. You could try to use a JavaScript based Value Set. See https://jazz.net/library/article/1093 lab 5 for some training and additional information. You can add dependent attributes and use them for your calculation. You need probably to return the resolution values configured in the process. As the worksho will explain, you will have to code the values used for the value set into the script or the configuration, because you will not be able to access the process configuration details from inside the script. Comments Isn't Workflow Resolution a NON-Attribute type variable
Sam,
what attribute? the resolution code is NOT an ATTRIBUTE...
Ralp, did I miss something in your explanation? How did you get these two things to be defined as Attribute types?
Sam, there is an attribute on my defect for example (4.0.1) called resolution. See this image.
yeh I see that, but the presentation lists something else. "Workitem Resolution"
showing 5 of 6
show 1 more comments
|
![]()
Adding my 2 cents to this interesting case: based on The default value for resolution should be configurable (58950)
comment 2: The resolution depends on the action selected, which is not even a work item attribute we can observe that we can enable / disable / filter resolution based on action only (workflow implementation) An alternate option to Javascript based calculated values would be to replace this resolution with a custom resolution enum attribute, and implement a new dependent enum between custom resolution and custom attribute (assuming this is an enum). Not tested, unknown impact. |
![]()
right, you would have to create a new field enum/variable to connect it to the primary field (dependent)
I suspect there will be fun times with queries, reports and other actions that are hard coded to the special variable. |