It's all about the answers!

Ask a question

"The selected value is not applicable"


Michael Whitner (5611010) | asked Mar 19 '12, 4:23 p.m.
I've created a new process template that I will be using to replace the process for an existing project. I made this new process template by extracting the process template from an existing project. My modifications heavily modified the work items, specifically Defects. I added many enumerations, custom attributes, value set dependencies and editor presentations.

I created a new "master" project using the new process template and I've enabled the "master" project to "Allow other project areas to use this project area's process."

I've modified the existing project to "Use the process from another project area:" and I've selected the "master" project from above and pasted the process configuration source from the "Unconfigured Process."

Initially all of the presentations that displayed enumerations that were in the associated by value sets showed "The selected value is not applicable" when trying to create a new Defect work item. I then realized that I need to define the associations in the existing project. After defining the associations a couple of enumerations no longer displayed the "The selected value is not applicable" error. However, there are still several that display that error and they all have 2 enumerations in common.

I've looked at the suspect enumerations and they follow the same naming conventions that I've used for the other enumerations. I've scoured the source and all references to the enumerations are consistent. Below is everything related to one of the malfunctioning presentations (ClosedInVersion).

<enumeration attributeTypeId="com.ibm.team.workitem.enumeration.mycompany.Version" name="Version">
<literal default="true" id="com.ibm.team.workitem.enumeration.mycompany.Version.literal.l1" name="Unset" null="true"/>
<literal id="com.ibm.team.workitem.enumeration.mycompany.Version.literal.l2" name="Others TBD"/>
</enumeration>

<enumeration attributeTypeId="com.ibm.team.workitem.enumeration.mycompany.Product" name="Product">
<literal default="true" id="com.ibm.team.workitem.enumeration.mycompany.Product.literal.l1" name="Unset"/>
<literal id="com.ibm.team.workitem.enumeration.mycompany.Product.literal.l2" name="A/>
<literal id="com.ibm.team.workitem.enumeration.mycompany.Product.literal.l3" name="B"/>
<literal id="com.ibm.team.workitem.enumeration.mycompany.Product.literal.l4" name="C"/>
</enumeration>

<valueSetProvider id="com.ibm.team.workitem.valueproviders.VALUE_SET_PROVIDER._kQY1QGxnEeGgcqoH6C9aMw" name="Product Version" providerId="com.ibm.team.workitem.common.internal.attributeValueSetProviders.FilteredValueSetProvider">
<mapping dependentEnumeration="com.ibm.team.workitem.enumeration.mycompany.Version" sourceEnumeration="com.ibm.team.workitem.enumeration.mycompany.Product"/>
</valueSetProvider>

<valueSetProvider id="com.ibm.team.workitem.valueproviders.VALUE_SET_PROVIDER._LBw9kGxPEeGgcqoH6C9aMw" name="Product Functiaonality" providerId="com.ibm.team.workitem.common.internal.attributeValueSetProviders.FilteredValueSetProvider">
<mapping dependentEnumeration="com.ibm.team.workitem.enumeration.mycompany.Functionality" sourceEnumeration="com.ibm.team.workitem.enumeration.mycompany.Product"/>
</valueSetProvider>
<valueSetProvider id="com.ibm.team.workitem.valueproviders.VALUE_SET_PROVIDER._kQY1QGxnEeGgcqoH6C9aMw" name="Product Version" providerId="com.ibm.team.workitem.common.internal.attributeValueSetProviders.FilteredValueSetProvider">
<mapping dependentEnumeration="com.ibm.team.workitem.enumeration.mycompany.Version" sourceEnumeration="com.ibm.team.workitem.enumeration.mycompany.Product"/>
</valueSetProvider>
<valueSetProvider id="com.ibm.team.workitem.valueproviders.VALUE_SET_PROVIDER._ruHyIGxnEeGgcqoH6C9aMw" name="Portfolio Product" providerId="com.ibm.team.workitem.common.internal.attributeValueSetProviders.FilteredValueSetProvider">
<mapping dependentEnumeration="com.ibm.team.workitem.enumeration.mycompany.Product" sourceEnumeration="com.ibm.team.workitem.enumeration.mycompany.Portfolio"/>
</valueSetProvider>

<attributeDefinition id="com.ibm.team.workitem.attribute.mycompany.ClosedInVersion" name="Closed In Version" type="com.ibm.team.workitem.enumeration.mycompany.Version">
<valueSetProvider providerId="com.ibm.team.workitem.valueproviders.VALUE_SET_PROVIDER._kQY1QGxnEeGgcqoH6C9aMw"/>
<dependsOn id="com.ibm.team.workitem.attribute.mycompany.Product"/>
</attributeDefinition>

<customAttribute id="com.ibm.team.workitem.attribute.mycompany.ClosedInVersion" name="Closed In Version" type="com.ibm.team.workitem.enumeration.mycompany.Version"/>
<customAttribute id="com.ibm.team.workitem.attribute.mycompany.Product" name="Product" type="com.ibm.team.workitem.enumeration.mycompany.Product"/>

<presentation id="com.ibm.team.workitem.presentation.mycompany.ClosedInVersion" attributeId="com.ibm.team.workitem.attribute.mycompany.ClosedInVersion" kind="com.ibm.team.workitem.kind.enumeration" label="Closed in Version">
<property key="labelVisible" value="true"/>
</presentation>

Any help would be greatly appreciated.

6 answers



permanent link
Ralph Schoon (63.7k33648) | answered Mar 20 '12, 3:58 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Michael,

if you want to share a process from another project area, you should use the template "Unconfigured Process". I have tried that and it works. The reason is, if you have a customized project area it has all process data already. So you have at least overwritten all the process information you want to use from the other project area.

I have never tried to cut down the process of an existing project area, so I don't know if that is possible and have no guidance.

I understand what you are trying however and it makes sense to be able to "demote" the process to a shared project area. I am just not sure it is so easy to do with RTC today. I would assume that this was not a use case that was considered. You could create an enhancement request.

permanent link
Michael Whitner (5611010) | answered Mar 20 '12, 5:26 a.m.
Hi Michael,

if you want to share a process from another project area, you should use the template "Unconfigured Process". I have tried that and it works. The reason is, if you have a customized project area it has all process data already. So you have at least overwritten all the process information you want to use from the other project area.

I have never tried to cut down the process of an existing project area, so I don't know if that is possible and have no guidance.

I understand what you are trying however and it makes sense to be able to "demote" the process to a shared project area. I am just not sure it is so easy to do with RTC today. I would assume that this was not a use case that was considered. You could create an enhancement request.


This is the approach that was suggested by Geoffrey Clemm in https://jazz.net/forums/viewtopic.php?t=22484&highlight=. I'm just starting to look at the existing project with the changed process.

permanent link
Ralph Schoon (63.7k33648) | answered Mar 20 '12, 6:08 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi, I checked the tread and what Geoff says:
"One approach if you do want to be able to upgrade the
process of the project area is to "share" the process of another project
area, and then when you want to modify the process, select a different
project area to "share" from." is correct, but it is intended to be used at the beginning of the project - the way I described, I believe.

I have briefly looked into process sharing and noticed that the granularity is not as small as you wish. E.g. if you create a work item type in the area that shares, you overwrite the whole sharing for all types.

You effectively overwrite the process you inherit completely. I am unsure what effects that could have and i don't see what you would gain, because I would assume your changes in the project area that lets the precess be shared will be hidden to the other project area because of this.

I would suggest to do all those experiments on a test server. You could try to set it up as I describe above on a test server and compare the process configuration of the project area created with the "unconfigured process" template to what you have in your current setup.

You could also recreate the situation you have now and try to minimize the template of the project area that shares the other process to a point where it works.

permanent link
Michael Whitner (5611010) | answered Mar 20 '12, 7:16 a.m.
Hi, I checked the tread and what Geoff says:
"One approach if you do want to be able to upgrade the
process of the project area is to "share" the process of another project
area, and then when you want to modify the process, select a different
project area to "share" from." is correct, but it is intended to be used at the beginning of the project - the way I described, I believe.

I have briefly looked into process sharing and noticed that the granularity is not as small as you wish. E.g. if you create a work item type in the area that shares, you overwrite the whole sharing for all types.

You effectively overwrite the process you inherit completely. I am unsure what effects that could have and i don't see what you would gain, because I would assume your changes in the project area that lets the precess be shared will be hidden to the other project area because of this.

I would suggest to do all those experiments on a test server. You could try to set it up as I describe above on a test server and compare the process configuration of the project area created with the "unconfigured process" template to what you have in your current setup.

You could also recreate the situation you have now and try to minimize the template of the project area that shares the other process to a point where it works.


Ralph,

Thank you for your responses!

In the thread that I have referenced earlier the very first paragraph states:

This task consists of merging project templates from 2 different RTC (v3.0.1) projects into a single combined template. The projects are hosted on 2 different Jazz Team Servers. Once the templates have been merged both projects must be updated to use the combined template and the data in both projects must be mapped to the new template. Both templates appear to be based on the "Scrum" template. One template has some customizations and the other has been customized heavily.

It was clear (at least I though) that this endeavor was to modify existing projects' process templates not to create new projects based on the combined process templates. Furthermore, the "Changing Templates" thread talks about "fixing up" project data after inheriting the new process template. There would be no need to fix-up data if this process was only intended to be used at the birth of a project.

I am not modifying anything in the child project's process template other than to specify the value set associations specific to the child project. The master project holds the super set of data for all the projects value sets. This is a technique that is being used in another RTC project.

I am doing this on a limited test server. I would have liked to be able to make a clone of these projects (https://jazz.net/forums/viewtopic.php?t=22779&highlight=) but, that isn't supported which seems to be a big limitation. So I've had to settle for exporting and importing work items.

We are wandering from the "The selected value is not applicable"" issue that I'm trying to address. I see this issue when I try to create a new work item.

permanent link
Ralph Schoon (63.7k33648) | answered Mar 20 '12, 7:48 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Michael,

I am not wandering away from your original question. I recon that when creating the work items the tool gets confused with the process you refer to and the process that is applied. The tool seems to say the values are not applicable to the work item. My interpretation with your setup is the project area s missing the enumerations or the ones found don't match the ID that is used. I would consider that because of the process usage not working as you expect.

i could be wrong, wouldn't be the first time.... 8-)

permanent link
Michael Whitner (5611010) | answered Mar 20 '12, 3:27 p.m.
Hi Michael,

I am not wandering away from your original question. I recon that when creating the work items the tool gets confused with the process you refer to and the process that is applied. The tool seems to say the values are not applicable to the work item. My interpretation with your setup is the project area s missing the enumerations or the ones found don't match the ID that is used. I would consider that because of the process usage not working as you expect.

i could be wrong, wouldn't be the first time.... 8-)


Ralph,

I have been using the following pattern for naming my custom attributes:

com.ibm.team.workitem.attribute.sterling.AttributeName

For whatever reason when I changed the custom attribute's ID in the master project's configuration and updated the editor presentation it worked in the child project just as expected. I changed the custom attribute's ID for every item that was being flagged with "The selected value is not applicable" and they all started working as expected.

Here's the really interesting part. I imported that same process template under a different name/ID, created a new master project, had the child project inherit from the new master project and different custom attributes were flagged. Changing their ID's solved the issue. I'm pasting a portion of the custom attributes from the process configuration source.

<customAttribute id="com.ibm.team.workitem.attribute.sterling.TestFailReason" name="Test Fail Reason" type="com.ibm.team.workitem.enumeration.sterling.TestFailReason"/>
<customAttribute id="com.ibm.team.workitem.attribute.sterling.TestedBy" name="Tested By" type="contributor"/>
<customAttribute id="com.ibm.team.workitem.attribute.sterling.VerifiedByQAInBuild" name="Verified by QA in BUild" type="smallString"/>
<customAttribute id="com.ibm.team.workitem.attribute.sterling.VerifiedByQAInVer" name="Verified by QA in Ver" type="com.ibm.team.workitem.enumeration.sterling.Version"/>
<customAttribute id="com.ibm.team.workitem.attribute.sterling.Version" name="Version" type="com.ibm.team.workitem.enumeration.sterling.Version"/>
<customAttribute id="com.ibm.team.workitem.attribute.sterling.L3FixIDCreateDate" name="L3 Fix ID Create Date" type="timestamp"/>
<customAttribute id="Functionality" name="Functionality" type="com.ibm.team.workitem.enumeration.sterling.Functionality"/>
<customAttribute id="Sub-Functionality" name="Sub-Functionality" type="com.ibm.team.workitem.enumeration.sterling.Functionality"/>

No good reason as to why I had to drop "com.ibm.team.workitem.attribute.sterling." deviating from my naming convention to get Functionality and Sub-Functionality attributes to present correctly.

Thanks again,
Mike Whitner

Comments
Madhan Babu commented Mar 15 '13, 11:25 a.m.

Hi Michael,

I also face a similar problem..

Did you change the id in the Process Configuration Source?
Because in Eclipse client or in Web interface, it does not allow me to edit the id of a custom attribute.

Best regards
Madhan

Your answer


Register or to post 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.