...
[10:22:26 CST(-0600)] <jwennmacher> sure 
thanks for looking at this
[10:22:43 CST(-0600)] <EricDalquist> no problem
[10:22:50 CST(-0600)] <EricDalquist> thanks for doing all the hard parts 
[10:23:22 CST(-0600)] <EricDalquist> so it looks like the existing getColumnDescriptions method should work. For each group you can add one column per selected tab as specified in the form
[10:24:54 CST(-0600)] <jwennmacher> yes that part would work.
[10:25:50 CST(-0600)] <EricDalquist> and I think your solution from that email looks good
[10:26:13 CST(-0600)] <jwennmacher> Thanks
[10:26:33 CST(-0600)] <jwennmacher> I appreciate you looking at it!
[10:26:45 CST(-0600)] <EricDalquist> and I agree that once this work is done we can review the overall object hierarchy and see what we can do to simplify it
[10:27:03 CST(-0600)] <EricDalquist> the current aggregation /aggregationKey stuff is more dictated by the actual event aggregation side of things
[10:27:09 CST(-0600)] <EricDalquist> to make that as efficient as possible
[10:27:45 CST(-0600)] <jwennmacher> makes sense
[10:28:22 CST(-0600)] <jwennmacher> the collection/aggregation has to be fast. Reports, not so much
[10:28:44 CST(-0600)] <EricDalquist> yeah
[10:28:57 CST(-0600)] <EricDalquist> well and realistically the only slow part of reporting is the database query
[10:29:19 CST(-0600)] <EricDalquist> so that is more making sure we can get as much data as possible for the final report with as few db queries as possible
[10:31:11 CST(-0600)] <jwennmacher> Thanks for all your feedback and help. I'll make these changes and see how it goes.
[10:31:43 CST(-0600)] <EricDalquist> sounds good