Usage difficulties for aggregation definitions with BIRT 4.9.0

[Markus-Elfring]

I noticed finally that aggregation functionality can be inserted into the table widget which is provided by the tool “Eclipse BIRT Designer Version 4.9.0.v202203150031” for the construction of grouped listing reports.
I got the impression then that each call of the dialogue “Aggregation Builder” would extend the data binding.
The available bindings can be controlled in another corresponding dialogue.
It can happen then that multiple definitions are presented according to varying edit (or maintenance) status for aggregation properties.

💭 I would also appreciate if previously defined aggregation fields can be better reused instead of attempting questionable setting repetitions.

[SteveSchafer-Innovent]

I have also noticed that multiple aggregations of the same column on different levels are very redundant in the XML code and it has always bothered me, but I think it might be miss-guided to try to reuse that code. That's because it isn't really code. It's a specification that can include code (javascript) and it's closely tied to how aggregation works in BIRT. Nevertheless, it might be possible to introduce a short-cut: A way to specify an aggregation and tell the designer to replicate that aggregation on other group levels. This would increase the complexity of the designer so it would be a tradeoff.

[hvbtup]

A button to "clone" an aggregation (or any other data binding) could be helpful. Then one would only have to change the "column binding name" and the group level.
For another example, I sometimes have queries with column names like COL1, COL2, COL3 and have to treat these 3 columns in the same way, e.g. to compute a sum for COL1, a sum for COL2, a sum for COL3.
What I do (if there are more than a handful of such columns) is to edit the XML directly. But that's dangerous, one should only do this after a saving a backup of the (working) *.rptdesign file.