ValueSetProvider script in RTC 3.0

Unfortunately the RTC 3.0 UI did not provide a wizard for entering a scripted value set provider, but I found an example somewhere after doing a search, which I referenced when adding my value set provider script to the process configuration xml source. Also, when you open the project area and go to the links tab, you will find an 'attachments' pane which you can use to upload the script as an attachment to the process. The relative path used here is reflected in the path that goes into the xml. Whenever you work with the xml, make sure you have process configuration xml backups and that you don't work with live project areas in the event that a change is made that corrupts the xml.

I've not checked to see if 3.0.1 now provides the UI to configure this - if so, I'd recommend 3.0.1 as the safer approach to configuring this.

<!-- please note I've extracted the pertinent configuration data for this question from these configuration-data tags. There is actually other data in here -->



			<configuration-data final="false" id="com.ibm.team.workitem.configuration.workItemTypes" xmlns="http://com.ibm.team.workitem/workitemTypes">

			    <attributeDefinitions>

			        <!-- almcoe: added valueSetProvider to only provide a subset of the values on qc defect presentations -->

			        <attributeDefinition id="com.ibm.team.workitem.attribute.severity" name="Severity" type="severity">

			            <valueSetProvider providerId="com.citi.almcoe.FilteredSeverityValueSet"/>

			            <dependsOn id="projectArea"/>

			        </attributeDefinition>

			    </attributeDefinitions>

			</configuration-data>





			<configuration-data final="false" id="com.ibm.team.workitem.configuration.providers" xmlns="http://com.ibm.team.workitem/providers">

			    <valueSetProviders>

			        <valueSetProvider id="com.citi.almcoe.FilteredSeverityValueSet" name="FilteredSeverityValueSet" providerId="com.ibm.team.workitem.shared.common.internal.valueProviders.ScriptAttributeValueProvider">

			            <script class="com.citi.almcoe.FilteredSeverityValueSet" path="/workitem/scripts/common/FilteredSeverityValueSet.js"/>

			        </valueSetProvider>

			    </valueSetProviders>

			</configuration-data>

I have this working now, although it is somewhat of a hack, so use at your own risk - as I can't predict how future api changes might affect this approach. If you have an approach that doesn't rely on getChildren, let me know.

dojo.provide("com.citi.almcoe.FilteredSeverityValueSet");



dojo.require("com.ibm.team.workitem.api.common.WorkItemAttributes");

dojo.require("dojo.string");



(function() {



dojo.declare("com.citi.almcoe.FilteredSeverityValueSet", null, {

	constructor : function() {},

	getValueSet : function(attributeId, workItem, configuration) {

		console.log("com.citi.almcoe.FilteredSeverityValueSet version 1.1");

		var WorkItemAttributes= com.ibm.team.workitem.api.common.WorkItemAttributes;

		var wiType = workItem.getValue(WorkItemAttributes.TYPE);

		// using the getChildren method in order to get an array object type which can be returned

		// and can also be manipulated with javascript array commands

		// using [] directly to build the array did not work and rtc complained about a conversion error

		// org.mozilla.javascript.EvaluatorException: Can only convert instances of 'com.ibm.jdojo.internal.facade.ListScriptType',

		//                                            but got 'org.mozilla.javascript.NativeArray'

		var severityOptions= configuration.getChildren();

		// clean out any values from the List type of javascript array

		severityOptions.slice(0,0);



		if (wiType.indexOf("qc") === -1) {

				// QC does not have Unclassified or Critical

				severityOptions.push("severity.literal.l1"); // Unclassified

				severityOptions.push("severity.literal.l2"); // Minor

				severityOptions.push("severity.literal.l3"); // Normal

				severityOptions.push("severity.literal.l4"); // Major

				severityOptions.push("severity.literal.l5"); // Critical

				severityOptions.push("severity.literal.l6"); // Blocker

		} else {

				severityOptions.push("severity.literal.l2"); // Minor

				severityOptions.push("severity.literal.l3"); // Normal

				severityOptions.push("severity.literal.l4"); // Major

				severityOptions.push("severity.literal.l6"); // Blocker

		}

		return severityOptions;

	}

});

}) ();

I have this working now, although it is somewhat of a hack, so use at your own risk - as I can't predict how future api changes might affect this approach. If you have an approach that doesn't rely on getChildren, let me know.

dojo.provide("com.citi.almcoe.FilteredSeverityValueSet");



dojo.require("com.ibm.team.workitem.api.common.WorkItemAttributes");

dojo.require("dojo.string");



(function() {



dojo.declare("com.citi.almcoe.FilteredSeverityValueSet", null, {

	constructor : function() {},

	getValueSet : function(attributeId, workItem, configuration) {

		console.log("com.citi.almcoe.FilteredSeverityValueSet version 1.1");

		var WorkItemAttributes= com.ibm.team.workitem.api.common.WorkItemAttributes;

		var wiType = workItem.getValue(WorkItemAttributes.TYPE);

		// using the getChildren method in order to get an array object type which can be returned

		// and can also be manipulated with javascript array commands

		// using [] directly to build the array did not work and rtc complained about a conversion error

		// org.mozilla.javascript.EvaluatorException: Can only convert instances of 'com.ibm.jdojo.internal.facade.ListScriptType',

		//                                            but got 'org.mozilla.javascript.NativeArray'

		var severityOptions= configuration.getChildren();

		// clean out any values from the List type of javascript array

		severityOptions.slice(0,0);



		if (wiType.indexOf("qc") === -1) {

				// QC does not have Unclassified or Critical

				severityOptions.push("severity.literal.l1"); // Unclassified

				severityOptions.push("severity.literal.l2"); // Minor

				severityOptions.push("severity.literal.l3"); // Normal

				severityOptions.push("severity.literal.l4"); // Major

				severityOptions.push("severity.literal.l5"); // Critical

				severityOptions.push("severity.literal.l6"); // Blocker

		} else {

				severityOptions.push("severity.literal.l2"); // Minor

				severityOptions.push("severity.literal.l3"); // Normal

				severityOptions.push("severity.literal.l4"); // Major

				severityOptions.push("severity.literal.l6"); // Blocker

		}

		return severityOptions;

	}

});

}) ();

Hello,

Sorry about cross-posting, but we digged into tons of documentations and didn 't find the current way to upload a javascript file with the code to be used as a ValueSetProvider. Could you please explain how to do that? If it's a Validator, it's simple, there's an interface to upload, but not for ValueSetProvider.

Thank you very much!
Claudio Neves

Unfortunately the RTC 3.0 UI did not provide a wizard for entering a scripted value set provider, but I found an example somewhere after doing a search, which I referenced when adding my value set provider script to the process configuration xml source. Also, when you open the project area and go to the links tab, you will find an 'attachments' pane which you can use to upload the script as an attachment to the process. The relative path used here is reflected in the path that goes into the xml. Whenever you work with the xml, make sure you have process configuration xml backups and that you don't work with live project areas in the event that a change is made that corrupts the xml.

Tom,

Thanks for the reply. I've finally found where to upload the script. I was looking for a "Links" tab on the Web interface, NOT on Eclipse interface. After checking on Eclipse interface, it was just there! :)

Thanks for the tip of having backups of the process configuration, it's really very easy to mess it up.

We are used to make heavy ClearQuest customizations and we are having a hard time with the limitations of RTC. For example, in ClearQuest there is a field type that is a "Reference". A Reference is related to an specific Record Type (equivalent to work item type). On RTC, the only thing close to that is the "Work Item" kind of attribute, but it does not force referencing to an specific Work Item type, it can be any type. It's too open for the "smart" users that will be using it.

Thanks again,
Claudio Neves

In 3.0.1, the UI lets you create a scripted value set provider, but unfortunately it doesn't let you enter the path to the script, and you still need to configure that manually in the XML. There also appears to be no content assist for the script tag.
I've filed 171808: Content assist missing support for script tag for valueSetProvider tag.

For the issue about restricting a work item attribute to a particular type, I found an existing enhancement request:
99841: Restrict work item type in work item list custom attribute.

Just dropping a quick note here, I am using your workaround for the "Can only convert instances of 'com.ibm.jdojo.internal.facade.ListScriptType', but got 'org.mozilla.javascript.NativeObject'" error as I am also seeing this problem.

I have set a watch on this thread in the hope that a clean solution will be found. Thanks for the workaround.