Details
-
Sub-task
-
Resolution: Fixed
-
L3 - Default
-
None
-
None
-
Not defined
Description
Context:
See parent task. As described in the PR for the other subtask, the second iteration has the goal to refactor the actual aggregation logic. I've noticed the following points which would be nice to mitigate:
- range vs minMaxStats usage
- reduce timezone logic - would be nice to handle this in a more unified way rather than apply it in different methods
- further reduce utils usage
- unify edge case logic implementation
- "entry point" of dateAggregationService is slightly different for different date reports. Would be neat to unify this
We could address all these with a unified querybuilder/handler type thing which has a builder and holds all possibly relevant information (such as timezone, stats, dateField etc) and can build the required queries. This could be in addition to the DateAggregationService or completely replace it.
AT:
- the above points have been addressed with a refactoring of the groupBy date reports