It's all about the answers!

Ask a question

Known issue in RTC v5? Editing Process Config in Web Client strips per-attribute ValueProvider XML Configurations

Ryan Davidson (1151611) | asked Sep 16 '16, 11:15 a.m.
I have specified a generic script-based ValueProvider that utilises the 'Configuration' argument to the getValue Method to pass in some XML-based parameters defined in the process configuration source per attribute.

Example of the ValueProvider Definition for 2 different attributes below.

For Attrib1: One set of 'behaviour' specified for the value provider
<attributeDefinition id="attrib.RelatedCRCause" name="Caused By CR" type="smallString">
<valueProvider providerId="">
<behaviour appendto="End" checkdup="Yes" includelabel="No" separator=", " sourceattrib=""/>
For Attrib2: A different 'Behaviour' set specified for the same value provider
<attributeDefinition id="" name="GSD Caused By CR" type="mediumString">
<valueProvider providerId="">
<behaviour appendto="Replace" includelabel="No" sourceattrib="attrib.RelatedCRCause" subsource=","/>
The '<behaviour>' tag and its properties comes in through the 'Configuration' parameter of the GetValue method in the script and I use that to govern script behaviour.

Now the Problem:
When I make any change to attributes using the v5.0.1 web client, it then kindly strips away this per-attribute customisation XML in my ValueProvider definitions, resulting in an updated definition like below:
<attributeDefinition id="attrib.RelatedCRCause" name="Caused By CR" type="smallString">
<valueProvider providerId=""/>

This strikes me as a pretty serious flaw - making any attribute-related process configuration change in the web client destroys the correct behaviour of my project area.

Does anyone know if this is a know issue planned for fix? 
Is it intended behaviour (with the intention to stop supporting such per-attribute XML customisations for ValueProviders)?


Donald Nong commented Sep 18 '16, 9:41 p.m. | edited Sep 18 '16, 9:42 p.m.

Given the fact that you can only configure the additional script parameters ("behaviour" in your sample) in the Process Configuration Source tab using the RTC Eclipse client, my take is that the web client just doesn't have the capability to handle this. In other words, the web client is not aware of such customization made to an attribute. So it's a "limitation".

Ryan Davidson commented Sep 19 '16, 3:47 a.m.

Thanks Donald.

Yes, I take that as a given.

But surely it's a bug that the XML customisations are overwritten by the Web client. It means making even a trivial change to attributes using the web client will 'undo' the process customisation against those attributes that were made in the Eclipse client.

Obviously the workaround is to simply not use the Web Client to perform process alterations at all (which I don't), but was interested in knowing whether this were considered a bug in the Web Client, and if it's a known issue, and whether there is any intention to address it if known?

Donald Nong commented Sep 20 '16, 2:00 a.m.

I won't say it's a bug. It can be a "missing feature". You can argue that the web client does not provide the same functionalities as the Eclipse client, but they are not meant to be the same any way.
If the web client is not aware of the customization, there is no way that the customization can be preserved when the XML node is modified, as the tool needs to make sure the XML node being written back is valid.
You can request such feature to be implemented in the web client by opening an RFE.

Ryan Davidson commented Sep 20 '16, 3:53 a.m.

Thanks Donald

I'll raise as a RFE. My take is that the web client should preserve any attribute definition XML that is outside of the XML that is 'in scope' for it to generate, especially given the fact that the XML schema and the tool supports this behaviour. i.e.) The Web client need not be altered to allow you to maintain these customisations through the UI, but it should be aware that such customisation blocks could exist and re-instate them when its generating the attribute definition block.

One answer

permanent link
Ralph Schoon (63.2k33646) | answered Sep 20 '16, 3:34 a.m.

please file a PMR with support. I think this should not happen. I haven't seen that behavior and if it happens then I would consider it a defect.

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.