feat: Increments charts endpoint with related dashboards

[michael-s-molina]

SUMMARY

We're currently working on a new feature called cross-linking. As one of the examples of the feature, we want to show the dashboards related to a specific chart in the charts list and enable navigation and filtering. The screenshot below shows the concept:

To do that, this PR changes the charts list endpoint to also return the associated dashboards. The superset/models/Dashboard model already contains a slices property with a backref called dashboards which allows us to reference the dashboards from the Slice model.

This is the modified result:

"result": [{
   "id": 122,
   "slice_name": "Test",
   "dashboards": [
      {
         "dashboard_title": "Video Game Sales",
         "id": 9
      },
      {
         "dashboard_title": "Test",
         "id": 17
      }
    ],
    ...
}]

I also added the dashboards property to the list of searchable columns to allow queries in the form of:

api/v1/chart/?q=(filters:!((col:dashboards,opr:rel_m_m,value:17)), ...)

This will allow us to add a Dashboards filter in the charts list screen to find all the charts of a particular dashboard.

TESTING INSTRUCTIONS

1 - Check that the dashboards are returned as expected.
2 - Check that you can the charts list by a particular dashboard.

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

[dpgaspar]

Can you change test_get_chart and add dashboards to the expected_results. Or do a slight revamp of that test.
Would also be really nice to have a test for the new dashboard filter.

I'll checkout this PR to make sure it will not generate N+1 queries

[codecov]

Codecov Report

Merging #21518 (e6b0f22) into master (7d2f07e) will increase coverage by 0.00%.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #21518   +/-   ##
=======================================
  Coverage   66.67%   66.67%           
=======================================
  Files        1793     1793           
  Lines       68493    68495    +2     
  Branches     7275     7275           
=======================================
+ Hits        45665    45667    +2     
  Misses      20966    20966           
  Partials     1862     1862           

Flag	Coverage Δ
hive	53.08% <ø> (-0.01%)	⬇️
mysql	78.20% <ø> (+<0.01%)	⬆️
postgres	78.27% <ø> (+<0.01%)	⬆️
presto	52.98% <ø> (-0.01%)	⬇️
python	81.41% <ø> (+<0.01%)	⬆️
sqlite	76.76% <ø> (+<0.01%)	⬆️
unit	51.06% <ø> (+<0.01%)	⬆️

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

Impacted Files	Coverage Δ
superset/charts/api.py	85.98% <ø> (ø)
superset/db_engine_specs/pinot.py	97.36% <0.00%> (ø)
superset/connectors/sqla/models.py	90.60% <0.00%> (ø)
superset/db_engine_specs/base.py	89.58% <0.00%> (+0.01%)	⬆️
superset/models/core.py	90.21% <0.00%> (+0.02%)	⬆️

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

[bkyryliuk]

Everything looks good, there is a small risk that https://github.com/dpgaspar/Flask-AppBuilder/blob/449afe47b17298b57272762332f9c96ea6af0449/flask_appbuilder/api/__init__.py#L1517 may be ineffective in fetching the relationships.

If that will turn out to be the case, sqlalchemy has ways of addressing it with loading strategies: https://docs.sqlalchemy.org/en/14/tutorial/orm_related_objects.html#tutorial-orm-loader-strategies

[bkyryliuk]

perf wise, I don't see any regressions on staging and latency is very reasonable

[dpgaspar]

Checked for N+1 queries found nothing. All good!