feat: keep modal open when saving database failed

[ktmud]

SUMMARY

When adding or editing a database, users may fail to save the database because of a typo in their connection string. Keep the modal open makes it easier for them to correct the typo because they don't have to open the modal again.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

After

TEST PLAN

• Go to Data -> Databases, create or edit a datasource.
• Modal should keep open if saving was not successful.
• Modal should close if saving was successful.

ADDITIONAL INFORMATION

• Has associated issue:
• Changes UI
• Requires DB Migration.
• Confirm DB Migration upgrade and downgrade tested.
• Introduces new feature or API
• Removes existing feature or API

cc @riahk @nytai

[codecov-io]

Codecov Report

Merging #11618 (779d558) into master (a9f9c4b) will decrease coverage by 3.49%.
The diff coverage is 25.00%.

@@            Coverage Diff             @@
##           master   #11618      +/-   ##
==========================================
- Coverage   65.76%   62.26%   -3.50%     
==========================================
  Files         873      873              
  Lines       42316    42321       +5     
  Branches     3972     3979       +7     
==========================================
- Hits        27827    26350    -1477     
- Misses      14374    15791    +1417     
- Partials      115      180      +65     

Flag	Coverage Δ
cypress	?
javascript	62.82% <11.11%> (-0.03%)	⬇️
python	61.91% <66.66%> (-0.01%)	⬇️

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

Impacted Files	Coverage Δ
...uperset-frontend/src/utils/getClientErrorObject.ts	86.48% <ø> (-2.71%)	⬇️
...tend/src/views/CRUD/data/database/DatabaseList.tsx	79.31% <ø> (ø)
...end/src/views/CRUD/data/database/DatabaseModal.tsx	55.33% <0.00%> (-13.42%)	⬇️
superset-frontend/src/views/CRUD/hooks.ts	56.55% <50.00%> (-7.09%)	⬇️
superset/models/core.py	88.82% <60.00%> (-0.43%)	⬇️
...set-frontend/src/common/components/Modal/Modal.tsx	100.00% <100.00%> (ø)
superset/databases/schemas.py	100.00% <100.00%> (ø)
superset-frontend/src/SqlLab/App.jsx	0.00% <0.00%> (-100.00%)	⬇️
superset-frontend/src/explore/App.jsx	0.00% <0.00%> (-100.00%)	⬇️
superset-frontend/src/dashboard/App.jsx	0.00% <0.00%> (-100.00%)	⬇️
... and 162 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a9f9c4b...779d558. Read the comment docs.

[dpgaspar]

@ktmud can we just show the actual message from the field? the structure for the backend error messages follows the marshmallow way, so, we get for each field an error message, this way the user can be warned about multiple errors from multiple fields in one go.

[ktmud]

@ktmud can we just show the actual message from the field? the structure for the backend error messages follows the marshmallow way, so, we get for each field an error message, this way the user can be warned about multiple errors from multiple fields in one go.

That would require a much bigger refactor so maybe let's work it in another PR.

@riahk @nytai do you mind picking it up from here?

[ktmud]

The API sometimes has message being a dictionary of validation errors by field name, but the frontend is not able to handle that. This is just a one-off stop-gap fix which is not very scalable.

We should do a larger refactor to either explode the validation errors as multiple Error objects from the server side, handle them within getClientErrorObject, or more preferably, in superset-ui/core's makeApi.

I'll add this to my todo but if anyone will be working on this area soon, feel free to take over.

cc @etr2460 since you've been working on client-side error messages.

[ktmud]

@nytai could you help with reviewing this PR? I think current solution is at a mergeable state.

We could take another look at generalizing inline async validation errors as @dpgaspar suggested at another time.

[nytai]

Yes, this LGTM. As far as per-field error handling, this is an issue for all our create/edit modals. We really should have a form state with per-field errors so that we can display them inline on the form instead of in toasts. That's beyond the scope of this PR, but it is an issue with these new react crud views/forms.

[nytai]

I'll do some manual testing in a bit before ✅