Clone TimeboxReportService
What does this MR do and why?
The feature update proposed in #381879 requires making a significant change to TimeboxReportService
class. However, the service class is complex and cannot easily be updated in place.
In this MR,
-
I am going to create a copy of
TimeboxReportService
so that I can modify it without touching the original in later MRs.-
I am splitting the copy of
TimeboxReportService
into two new service classesTimebox::EventAggregationService
andTimebox::RollupReportService
.- In other words
TimeboxReportService
=Timebox::EventAggregationService
+Timebox::RollupReportService
(it's barely a refactor because I am merely shifting around the methods/attributes etc as they are.)
- In other words
-
-
Introduce a new FF
rollup_timebox_chart
.- When this FF is enabled, the consumer of
TimeboxReportService
will instead useTimebox::RollupReportService
.
- When this FF is enabled, the consumer of
The purpose of the above changes is 1) to ensure we can continue to serve the original TimeboxReportService
to users should we find regressions in the updated implementation and 2) to allow future reviewers to easily understand what new changes are being made to Timebox::EventAggregationService
and Timebox::RollupReportService
(it's better than cloning and making changes at the same time.)
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.