Sample report required

Hi there

I have been struggling with the pleasures of BIRT for a few days now - it has to be one of the most frustrating reporting packages in the market!!!

Can anyone send me a report that I can use as a starting point so that I can see work items in a tree structure. We use links like block/depends on and parent/child but without being able to see the structure it is almost useless.

Many thanks

David

Did you see this video on jazz.net for reporting across links?

http://jazz.net/library/video/285

Are you looking for something like this:

http://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.reports.viewQuery&queryUUID=_Zie0cKL8Ed6i6JlT0obBVg&name=Work%20Progress%20%28Live%29

You can find the report design in:

https://jazz.net/wiki/bin/view/Main/ReportsCentral#Work_Progress

Some of those are close.

We are basically after something that shows ( for the current sprint ) all work items ( showing their type ) and below them any items that are linked to them ( showing their link type ). Totaling up the effort would be a nice to have.

Anyone know of anything ??

How about this?

http://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.reports.viewQuery&queryUUID=_wS6G4ImjEd6HzLSYRe2U4w&name=Work Item Closure (Live)

The report design can be found under:

https://jazz.net/wiki/bin/viewfile/Main/ReportsCentral?rev=3;filename=Work_Item_Closure.rptdesign

Not really, we are specifically looking to get a list of all work items with any linked ones listed below in a tree format. eg

<Story> <123456> <THis> <In>
<Task> <123457> <Create> <Resolved> <Blocks>
<Task> <123458> <Create> <new> <dependson>

By suggesting the reports above, I am pointing you to some examples that you can use to use to design your report templates.

I am not sure how your tree structure is going to handle circular dependencies. Here an example:

1 is parent of 2.
2 blocks 1.

1 <in>
2 <blocks>
1 <infinite>

Also how does your tree structure represent this case?

1 is parent of 2
1 blocks 3

may be:

1 <in>
2
1<blocks>
3

trees are good at representing one kind of relationship. I have yet to see a tree that represents multiple kinds of relationships.

For multiple kinds of relationships, graphs (diagrams) are a better representation. That is why we have UML :-)

Thanks for your help on this. Basically it was some of the analysts who wanted to be able to pull out links, probably one type at a time. ie list all work items that depend on something else. I think they wwere looking for a report in which they could choose the type of link.
I agree , diagrams are better and we use these for all of our modelling. Just doesn't help us much when the modelling turns into work items and stories.

Many thanks again.

David