Hi,

the user I referred to is the RTC administrator. To give him guidance on what type/format of strings the advisor configuration can handle.

The problem is that for the built-in attributes, if I reference in the plugin the internal ID, for example, com.ibm.team.workitem.attribute.summary has to be converted using something like (or make the code internal names mapping aware):

String internalAttributeId= WorkItemAttributes.getAttributeId(Identifier.create(IAttribute.class, attributeId));

and then you can fetch the IAttribute to act over it:

IAttribute attribute= workItemCommon.findAttribute(workItem.getProjectArea(), attributeId, monitor);

As WorkItemAttributes states:

* This mapping can be used to retrieve attribute ids for built-in attributes
* providing a property identifier and vice-versa.
* Custom attributes always map to an identifier have the attribute id as identifier string.

Thanks!

Regards,

Jorge.

Yes, I try to put things in order ;)

- We are developing precondition plugins with configuration source to allow our RTC administrators modify its parameterization.

- One of the plugins parameters is the attributes they act on. So we accept for our precondition the ability to specify attributes IDs in its configuration part in the Process source xml.

- What we try to support is that, no matter custom or built-in attributes, give administrators the ability of specifying the attribute ID for these parameters. As general rule to simplify their tasks.

- In order to make the code consistent; for the built-in attributes, if the administrator adds a new value specifying the attribute ID (for example com.ibm.team.workitem.attribute.summary) the code has to find a way of getting the translated property to get the IAttribute object and continue with the logic,, that's why I added the code in the previous post.

Thanks!

Regards,

Jorge.