It's all about the answers!

Ask a question

Design question: LinkTypes vs. Attributes?

Ilona Krammer (159237) | asked Jan 11 '17, 1:50 a.m.
edited Jan 11 '17, 1:51 a.m.

We were recommended to use LinkTypes for custom connections between work items (we basically rebuilt everything in RTC because it just didn't work at all with our processes - and since we were told that we could configure RTC basically the way we wanted - we did).
We have a lot of those actually.

But in the process of adding some custom functionality I am getting my doubts if that was the right decision. Of course it is great to have a bidirectional connection between elements, which is actually what we definitely need - but it seems to have a lot of downsides as well:
- with attributes I should be able to have a mandatory attribute, with link types I have to write a plugin for that
- I should be able to detect changes (added or deleted items) when using attributes and it seems like I can't do that with linktypes - am I correct on that?

Even though with attributes I have to create the back link myself and that isn't done automatically, that would be a downside of that.

As far as I've understood, with both possibilities there is no way to create reports that span more than 2 levels, so item A references item B references item C references item D and with the report I can only ask for item B, but not further. In fact I'd need that with a lot more levels than 2.

Can you guys give me your thoughts on that?

EDIT: upgrading to 6.0.3 as of today

One answer

permanent link
Ralph Schoon (61.8k33643) | answered Jan 11 '17, 4:48 a.m.
edited Jan 11 '17, 6:01 a.m.

In general, RTC is customizable. Like with every tool, there are limitations in what can be done and it is a good advice to stay within the limitations. Some limitations can be overcome if throwing enough custom coding and computational power at them, some can't. So it is a good idea to understand the limitations. Here material I presented last year about what I think the limits are:

RTC does not support any custom data types similar to e.g. Clear Quest stateless records. So it is impossible to define and use such built in business objects and have effects like changing such a stateless record and have all work items/work item attributes referring to that record reflect the change. There is no mechanism in RTC to define a way to present multiple attributes of a complex referenced object in the work item or pull information from a referenced object into the work item for display on open. There is no real solution to implement anything like this in RTC, I would be aware of. From my perspective, this kind of behavior is one of the things you can not achieve in RTC.

It is possible to some extend to use RTC work items to store custom data and use either work item/work item list type attributes or links to store the relationship. Still, if the work item is changed, the change is not reflected in the source work item refering to that work item (except the summary displayed). There is also a host of other limitations e.g. there is no built in mechanism to define a query for work items to choose from in the attribute presentation/value picker.

I think it is important to note, that RTC was not intended to replace extremely customizable change management tools that support most complex custom business processes. The intent was to have a simple tool that supports agile development with some basic customization capabilities. This is what RTC is and it got pushed a little bit further over the years. However, I think RTC needs something like stateless records, if customer want so complex business logic and would welcome enhancement requests from customers. Using String type values via the HTTP filtered value sets does also not address the update issue. 

Using Reference Presentations to Create Links and Show Linked Work Items in RTC allows to refer to work items that are linked and to display them. The work items however are not updating linked work item values automatically. In fact the whole idea of OSLC is to avoid all these update dependencies and all the problems they entail. You can use follow up actions to do automation, with the usual penalty. Note that link changes can not be detected for OSLC links. Only Work Item Link type changes can be detected in operational behavior. See for link types. You can only create custom link types for work item links.

Using real attributes to represent connections and manage back links etc is most likely the wrong decision. Attribute values are not meant as a two directional relationship. In addition attribute values are incapable of representing M:N relationships. Any attempts to use customization to keep attribute references stable are likely to be brittle and drain performance. I would stay away from such attempts.

As mentioned links have other limitations. Without really knowing what the use case and the underlying business case is, there is no way to provide a good answer.

Ilona Krammer commented Jan 11 '17, 7:01 a.m.

I do not need individual attributes from one work item in the other - I just need a link to the other work item. So I'm guessing I can ignore the complete first part of your post as far as I understand. Besides - that wouldn't be something to decide either way (link types or work item lists) because it doesn't work either way.
And yes - I have noticed that RTC isn't exactly as customizable as IBM likes to sell it. If you're trying to do anything your way and not the way that is already built in you're stuck with errors and erratic program behavior pretty soon

Obviously the problematic parts haven't come out clearly or there is no real answer to them because you are not really answering those at all, so I'm trying to rephrase the  most important points into questions so it might become clear:
- is there a way for us to detect added and deleted links as soon as a work item is stored (which as far as I understand it right now is the benefit of using work item lists instead of linktypes)
- is there any way to make reports across more levels than two (it seems that doesn't work either way right now but is a huge problem)

Ilona Krammer commented Jan 11 '17, 7:03 a.m.

Besides of course it would be interesting how those two possibilities compare in other ways as well.

And some additional info (sry): I am talking about custom link types, not the built in ones (they are way too unpredictable and not at all phrased like we would need them to be)

Ralph Schoon commented Jan 11 '17, 7:30 a.m. | edited Jan 11 '17, 7:33 a.m.

Yes, you can detect added and deleted work item links using custom advisors as far as I can tell. You have to look at the links in the old state and compare them to the links in the new state. Note, i did a prototype but that was for a link type that DOES NOT TRIGGER THE ADVISOR (the aforementioned CLM link types such as tracks). So I gave up on it. No, you can not use work item attribute customization/JavaScript.

No, you can not report across custom link types at all. Multiple level is not a question as custom link information is not stored in the report service data warehouse at all (as far as I am aware).

Miguel Tomico commented Jan 11 '17, 8:13 a.m.

Excellent responses and brilliant slides about what can and cannot be done, @rschoon

This question is another example of the importance of having someone with the knowledge of the tool advising along the way.
For starter, I would strongly discourage creating custom LinkTypes.

RTC can be quite powerful, capable of supporting complex custom use cases, if implemented properly and accepting small sacrifices.
I see here at more and more questions with requirements which are questionable. I wonder if sometimes it's a problem of expectations and lack of in-depth knowledge of the tool, which is key when adapting the tool to customers' needs.
What sometimes looks like a big limitation in the tool can be easily overcome using a different approach and being a bit flexible.

Ralph Schoon commented Jan 11 '17, 8:27 a.m. | edited Jan 11 '17, 9:52 a.m.

There are several problems leading to questionable questions 8)).

1) A lot of questions recently are not very well written and lack even the most basic details. This is my personal observation and I am reading most of the RTC related questions the last 9 years.

2) With respect to RTC/CLM customization A lot of questions ask if or how some imagined custom behavior can be implemented.

Very often someone with a lack of experience has thought about implementing something to achieve some goal, due to some request, assuming that the API's/extension mechanism will support this.

The problems: The API's, especially JavaScript attribute customization don't work as hoped for. The documentation is limited and users jump to conclusions (e.g. access links, users, roles, teams,.... in JavaScript attribute customization)

As described in we need more details and we need the what and why some customization is supposed to be done and usually not how one wants to implement it to be able to help.

Ralph Schoon commented Jan 11 '17, 8:32 a.m. | edited Jan 11 '17, 8:41 a.m.

Don't get me wrong, there is a lot of information on this particular question, even if I misunderstood it or did not get the main topics the first time around. And as Miguel mentions, this is complex and even very experienced users sometimes can only answer "I think this would be a way to solve the need".

Another Issue with customization is that users often try to solve organizational issues with customization. This has never been and never will be a good idea and often leads to complicated workflows that frustrates the users. If organizational issues can't be solved with the users, you can almost never solve them against the users with customization.

Finally a lot of users try to use JavaScript to get around writing real Java based extensions, because the deployment is easier. I would be happy if the JavaScript stuff would be removed for various reasons, including a too low usage threshold and potential performance impacts and other limitations.

Ilona Krammer commented Jan 12 '17, 1:33 a.m.

I'm sure you can imagine that I cannot disclose all the company information that lead to the decision to implement things the way we are doing right now.

And I am absolutely with Miguel - I'd love to have an expert to help along the way. The thing is that there are none really! Not even IBM gives accurate and full information. For a lot of questions we are not getting any usable answers. The same goes for some external people we are talking to who say they know the tool and in the end it turns out they don't really. Unfortunately that turned out quite late. Are there any real experts? Is there some kind of reference list for advisors?

And unfortunately with all your answers I am none the wiser what to use.

Ralph Schoon commented Jan 12 '17, 2:27 a.m.

I think your expectation is way off. We are not talking about standard tool usage and configuration here. This is basically custom development and unless you have a prototype that works, all bets are off. I consider myself an expert in these areas, but I would not dare to say I could do stuff unless I prototype it. Luckily I have done a lot of prototypes

This is basically consulting land and it is unrealistic to get definitive answers without investing time, resources and money into exploration.

In the context of the forums here the answers you get are as good as they can be, provided they are for free and you can't share your company information.

showing 5 of 8 show 3 more comments

Your answer

Register or to post your answer.