fix: moved alerts and reports default values to config

[Always-prog]

SUMMARY

Typically, users do not verify the working timeout and default repetition for creating alerts or reports. As a result, if a Superset administrator wants to change the default values for these options, they need to modify the code. To address this issue, I submitted a pull request that moves these default values to the config file.

ADDITIONAL INFORMATION

• Has associated issue:
• Required feature flags:
• Changes UI
• Includes DB Migration (follow approval process in SIP-59)
  • Migration is atomic, supports rollback & is backwards-compatible
  • Confirm DB migration upgrade and downgrade tested
  • Runtime estimates and downtime expectations provided
• Introduces new feature or API
• Removes existing feature or API

[codecov]

Codecov Report

Merging #22880 (5157886) into master (260ac40) will decrease coverage by 0.01%.
The diff coverage is 72.62%.

❗ Current head 5157886 differs from pull request most recent head a150689. Consider uploading reports for the commit a150689 to get more accurate results

@@            Coverage Diff             @@
##           master   #22880      +/-   ##
==========================================
- Coverage   67.40%   67.39%   -0.01%     
==========================================
  Files        1876     1880       +4     
  Lines       72084    72229     +145     
  Branches     7857     7882      +25     
==========================================
+ Hits        48587    48678      +91     
- Misses      21480    21527      +47     
- Partials     2017     2024       +7     

Flag	Coverage Δ
hive	?
javascript	53.91% <68.75%> (+0.15%)	⬆️
mysql	78.24% <61.76%> (-0.02%)	⬇️
postgres	78.31% <61.76%> (-0.02%)	⬇️
presto	52.62% <52.94%> (-0.01%)	⬇️
python	81.96% <100.00%> (-0.15%)	⬇️
sqlite	76.62% <58.82%> (-0.02%)	⬇️
unit	52.51% <91.17%> (+0.08%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
...hart-controls/src/operators/timeCompareOperator.ts	100.00% <ø> (ø)
...-chart-controls/src/sections/advancedAnalytics.tsx	14.28% <ø> (ø)
...trols/components/ColumnConfigControl/constants.tsx	100.00% <ø> (ø)
...d/packages/superset-ui-chart-controls/src/types.ts	100.00% <ø> (ø)
...i-chart-controls/src/utils/expandControlConfig.tsx	100.00% <ø> (ø)
...perset-ui-core/src/chart/components/SuperChart.tsx	97.22% <ø> (ø)
...ages/superset-ui-core/src/math-expression/index.ts	100.00% <ø> (ø)
...ges/superset-ui-core/src/query/buildQueryObject.ts	100.00% <ø> (ø)
...ges/superset-ui-core/src/query/normalizeOrderBy.ts	100.00% <ø> (ø)
...superset-ui-core/src/query/types/PostProcessing.ts	100.00% <ø> (ø)
... and 133 more

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[villebro]

Nice improvement 👍 LGTM and tested to work as expected with one minor naming comment.

[Always-prog]

@villebro Hello!
I fixed the passing test cases because the test cases were running without the python config. We still need to have default values in the code. However, if they are declared in config, they will be used.
Can you check my code?

[villebro]

@villebro Hello!
I fixed the passing test cases because the test cases were running without the python config. We still need to have default values in the code. However, if they are declared in config, they will be used.
Can you check my code?

@Always-prog yeah, this is a bit of a problem when the frontend assets don't have context on regarding the python config values. You can probably either mock the values on the test (more work) or just add the same defaults on the frontend code path (less work). I'm ok with both, as in practice they won't affect this functionality.

[Always-prog]

@villebro Hello!
I fixed the passing test cases because the test cases were running without the python config. We still need to have default values in the code. However, if they are declared in config, they will be used.
Can you check my code?

@Always-prog yeah, this is a bit of a problem when the frontend assets don't have context on regarding the python config values. You can probably either mock the values on the test (more work) or just add the same defaults on the frontend code path (less work). I'm ok with both, as in practice they won't affect this functionality.

I added default values in code.

[villebro]

@Always-prog can you rebase the PR? That might help resolve that failed test.

[Always-prog]

Hello @villebro and @rusackas!
I have fixed the frontend tests and they are now passing. Could you please review my code once more?

[Always-prog]

I need to create a new PR for the fix?
There are many commits that are not mine, due to rebase.

[dpgaspar]

probably something went wrong with the rebase

[Always-prog]

probably something went wrong with the rebase

I reverted rebase commit.

[Always-prog]

On my fork all CI test has passed.

Maybe need to restart them @dpgaspar?

[villebro]

@dpgaspar I believe the rebasing problems have been resolved, can you take another look?

[Always-prog]

@dpgaspar Hello!
Can you please review py PR again?

[villebro]

LGTM, thanks for this and apologies for letting this get stale

The requested changes have been addressed

[Always-prog]

Thanks for approving!