[ ] Milestone 8: validate api (including forecaster and model level. e.g., max categorical fields honored and infer minimum interval?) and suggest (interval) api
[ ] Milestone 9: fault tolerance
[ ] resource (disk and memory) management in hourly and daily cron
[ ] circuit breaker
[ ] Milestone 10: upgrade rcf and data quality, recency bias (transformDecay in trcf), minimum shingle = 4
[ ] Milestone 11 default and custom result index, guard against modifying result index, alerting)
[ ] Test if custom result index still works or not (e.g., top forecast result api)
[ ] Milestone 12 security
[ ] In AD plugin user finds out that they don’t have the write permissions in the very end of the stepper flow, after configuring the model and the detector, which is frustrating (Playground is an example). Can we do the permission check in the beginning of the flow
[ ] security tests
[ ] Milestone 13 adjust based on ux design (state transition graph, specify history in cold start)
[ ] infer shingle size. Users can solicit shingle size explicitly or implicitly from ux in three ways: shingle size in advanced parameter, user specify seasonality, and users telling us how long they want to forecast.
[ ] For the error states user can access content of the full error message in a modal window
[ ] allow the compare data source or model parameters changes (e.g., using md5)
[ ] validate when users haven't specified interval yet (e.g., look at data source/filter and find the data is almost empty)
[ ] specify history in cold start
[ ] forecast range (cannot be more/less than a value)
Is your feature request related to a problem? This is a container to house forecasting feature requirements as they progress.
What solution would you like? Proposal
** Working issues
Frontend