* feat: add database dropdown to dashboard import
Currently, when importing a database from a JSON file, the process
looks at the database name from the source (the info is in the file)
and matches the datasources to that name. If no database by that name
exists, it simply fails.
With this PR, we add a database dropdown that allows the user to specify
which databases the datasources should target as the get upserted.
I want to stress that the code in this area is not in a great shape,
and that the challenge of serializing/deser the nested objects is
challenging, but that there should be a much better way to do this.
One of the improvement (out of scope for this PR) that would allow to
simplify those import/export would be to use UUIDs for
importable/exportable objects.
Another identified issue is the indirections between
`utils/import_expor_{model}.py` on top of `{Model}.import_object`. Not
addressing that here.
Next topic is the MVC stuff. Decided to stick with it for now as this is
more of a [obious missing feat:] than a rewrite.
* isort \!? 0%^$%Y$&?%$^?%0^?
* fix tests
* pre-committing to py3.6
* address dpgaspar's comments
* revert isort
* Add post processing to QueryObject
* Simplify sort signature and require explicit sort order
* Add new operations and unit tests
* linting
* Address comments
* Simplify test method names
* Address comments
* Linting
* remove unnecessary logic
* Apply strict whitelisting to all getattr calls
* Add checking of rolling_type_options and add/improve docs
* [dashboard] Refactor API using SIP-35
* [dashboard] Fix, import
* [dashboard] more tests
* [dashboards] a misc of improvements
* [charts] Fix, DAO and tests
* [dashboards] small exceptions refactor
* [dashboards] lint
* [dashboards] Improves comments on base classes
* [dashboards] lint
* Re-enable pylint for superset/jinja_context.py
* Re-enable pylint for superset/sql_lab.py
* Re-enable pylint for superset/sql_parse.py
* Re-enable pylint for superset/exceptions.py
* Re-enable lint for superset/translations/utils.py
* Re-enable pylint for superset/views/schedules.py
* Re-enable pylint for superset/views/base.py
* Re-enable pylint for superset/views/log/views.py
* Re-enable pylint for superset/views/annotations.py
* black
* PR feedback, pylint, isort fixes
* Black, one more time...
* Move ungrouped-imports to a global disable
* chore: deprecate restricted metrics
An early community contribution added the concept of restricted metrics.
The idea was to allow for some metrics to be restricted, and if a metric
was tagged as such, a user would need to be given access to that metric
more explicitely, through a special perm we would maintain for that
metric.
Now since the new concept of "Adhoc Metrics", the popover that lets a
user pick a column and an aggregate function or to write their own SQL
expression inline, this restriction is completely bypassed. Adhoc
metrics was developed without the restricted metrics in mind.
Anyhow, in the near future, we'll be rethinking the ideas behind
data-access permissions, and things like column-level or row-level
security will be redesigned from scratch.
By deprecating this feature, we're removing a confusing and mostly broken
feature, and making it easy to move forward
* Use context manager to drop columns
* disable jest's maxWorkers
Common mistake is trying to import dashboard without creating
datasources first. Currently it causes error 500 with a message
> sqlalchemy.orm.exc.NoResultFound: No row was found for one()
which is difficult to understand.
This commit catches NoResultFound error and returns human readable error
using flash('danger').
Ref: #2992
* [SIP-5] Open a new /api/v1/query endpoint that takes query_obj
- Introduce a new handle_superset_exception decorator to avoid repeating the logic for catching SupersetExceptions
- Create a query_obj_backfill method that takes form_data and constructs a query_obj that will be constructed in the client in the future. Use the backfill in explore_json.
- Create a new /api/v1/query endpoint that takes query_obj only and returns the payload data. Note the query_obj is constructed in the client. The endpoint currently only handles query_obj for table view viz (we'll be adding support to new viz types as we go).
- Unit test to verify the new endpoint for table view
* fix tests and lint errors
* - Move the new query endpoint into its own api.py view.
- Create QueryObject and QueryContext class to encapsulate query_object to be built from the client and additional info (e.g. datasource) needed to get the data payload for a given query
- Remove the query_obj_backfill as we'll start building the first query_object on the client so it no longer makes sense to have a short-lived backfill for the matter of days.
* Fixing lint and test errors
* Fixing additional lint error from the previous rebase.
* fixing additional lint error
* addressing additional pr comments
* Make /query accept a list of queries in the query_context object.
* fixing a lint error
* - Move time_shift based calculation and since, until check into util
- Add typing info for get_since_until
- Add new unit tests to verify time_shift calculation and the since until check
