Issue 1:
[SIP-30] Remove Tabs in SQL Lab

Motivation

SQL Lab is devoting screen space to a custom tab UI that is less effective than that offered natively by the browser. Other upcoming features such as more powerful edit history/undo, and better navigation/discovery make tabs less important. The new design directions coming from the superset design group specify a tabless UI. Browser-based tabs would be a better solution for nearly every SQL Lab use case.

Proposed Change

Remove the tab bar in SQL Lab

Include the id of the current queryEditor in the SQL Lab url: myapp.com/superset/sqllab/42

Links throughout Superset referencing SQL Lab queries should use urls with a queryEditor id

Implement a user-level flag to switch between the tabful and tabless UI

Stabilize backend-managed SQL Lab state, and make it the default option.

This change can actually be made without significant changes to state management. SQL Lab state includes some number of queryEditors ("tabs"). Instead of each queryEditor referencing an in-page tab, the SQL Lab url will contain the id of the queryEditor being used.

This will depend on the backend implementation of state management for SQL Lab which is currently behind a feature flag. Without backend SQL Lab state, your local state would accumulate until there is too much to manage, without a practical way to clean it besides clearing your localStorage or editing it laboriously.

One change that will be tricky is offering users a quality migration experience to the tabless UI. More details on that down the page.

A note on preventing lost work in a tabless UI

Nobody wants to write a query, then close their browser and lose it forever. Mitigating that in this new design will be important. The full UI/UX redesigns call for a robust history feature, but there are some things we can do to protect people's work without the history feature.

When you navigate to SQL Lab without specifying an id in the URL, an id will be generated for you just as if you had clicked the "+ tab" button in the current UI. This will allow users to re-open a closed tab from the browser history, even if they didn't save the query. If a user wrote a query but didn't save it, and closes the browser tab, SQLLab should also warn and offer to save the query before the tab closes. If you run or save your query, those will also be ways to recover your work.

Just for reference, here's the design we're working towards. This SIP is not about implementing everything on this screen, only replacing the in-page tabs with browser tabs.

New or Changed Public Interfaces

"Run query in a new tab" button in the query history will open a new browser tab.

"Share query" should use the new url format, and should save the query if it hasn't been saved.

Links in the saved queries screen and query search should use the new url format.

Remove the ctrl-t keyboard shortcut?

Migration Plan and Compatibility

We should allow users to migrate to the new system at their own pace. Tabs are a heavily-used feature, and should not be ripped out without a proper transition phase to educate and re-orient users.

A per-user feature flag will be added indicating whether they are using the tabful or tabless version of SQLLab. SQLLab will appear unchanged as long as a user's flag is off, with the exception of a small banner in the corner notifying the user of the new tabless experience, and allowing them to flip the flag on. Once they flip the flag SQLLab will change to the tabless UI. There should be an explanation of the change, with useful info on how to navigate this brave new world.

After some time, we can turn this flag on by default for new users. Eventually when the tabless UI is deemed stable, people are happy with the change, and we've made sure that there isn't a negative impact to existing user needs, we can switch everyone over.

Rejected Alternatives

Keeping in-page tabs - too cumbersome to use, not as accessible, adds unnecessary state complexity

Switching over immediately to a tabless UI without a feature flag - too jarring to users, want to give them the opportunity to change to the new system when it's convenient for them.

Developing the new SQL Lab designs in a separate screen alongside the original SQL Lab - too much code complexity and chance of breaking changes, not enough opportunity to reuse existing components.

Re-organizing SQL Lab frontend state around a tabless UI - too much work for now, and breaks compatibility between the new and old version of the page. It will likely make sense to re-organize state in a future release once all users have migrated to the tabless UI.

Issue 2:
A clear and concise description of what the bug is.

I tried running the following code:

git clone https://github.com/apache/incubator-superset/
cd incubator-superset
# you can run this command everytime you need to start superset now:
docker-compose up

as mentioned here - https://superset.incubator.apache.org/installation.html#start-with-docker

Expected results

Expect Superset UI to allow me to access it and it should work.

Actual results

The UI didn't recognize the credentials at first. Then I went inside the Docker container of superset named incubator-superset_superset and ran the following command:

superset fab create-admin \
--username admin \
--firstname Superset \
--lastname Admin \
--email admin@superset.com \
--password admin

which I copied from here - https://github.com/apache/incubator-superset/blob/master/docker/docker-init.sh#L36.

I got authenticated successfully but got an error page, the content of which is as following:

sqlalchemy.exc.ProgrammingError
sqlalchemy.exc.ProgrammingError: (psycopg2.ProgrammingError) relation "user_attribute" does not exist
LINE 2: FROM user_attribute
^

[SQL: SELECT user_attribute.welcome_dashboard_id AS user_attribute_welcome_dashboard_id
FROM user_attribute
WHERE user_attribute.user_id = %(user_id_1)s]
[parameters: {'user_id_1': '1'}]
(Background on this error at: http://sqlalche.me/e/f405)

Traceback (most recent call last)
File "/usr/local/lib/python3.6/site-packages/sqlalchemy/engine/base.py", line 1246, in _execute_context
cursor, statement, parameters, context
File "/usr/local/lib/python3.6/site-packages/sqlalchemy/engine/default.py", line 581, in do_execute
cursor.execute(statement, parameters)
The above exception was the direct cause of the following exception:
File "/usr/local/lib/python3.6/site-packages/flask/app.py", line 2463, in __call__
return self.wsgi_app(environ, start_response)
File "/usr/local/lib/python3.6/site-packages/flask/app.py", line 2449, in wsgi_app
response = self.handle_exception(e)
File "/usr/local/lib/python3.6/site-packages/flask/app.py", line 1866, in handle_exception
reraise(exc_type, exc_value, tb)
File "/usr/local/lib/python3.6/site-packages/flask/_compat.py", line 39, in reraise
raise value
File "/usr/local/lib/python3.6/site-packages/flask/app.py", line 2446, in wsgi_app
response = self.full_dispatch_request()
File "/usr/local/lib/python3.6/site-packages/flask/app.py", line 1951, in full_dispatch_request
rv = self.handle_user_exception(e)
File "/usr/local/lib/python3.6/site-packages/flask/app.py", line 1820, in handle_user_exception
reraise(exc_type, exc_value, tb)
File "/usr/local/lib/python3.6/site-packages/flask/_compat.py", line 39, in reraise
raise value
File "/usr/local/lib/python3.6/site-packages/flask/app.py", line 1949, in full_dispatch_request
rv = self.dispatch_request()
File "/usr/local/lib/python3.6/site-packages/flask/app.py", line 1935, in dispatch_request
return self.view_functions[rule.endpoint](**req.view_args)
File "/app/superset/views/core.py", line 2633, in welcome
.filter_by(user_id=g.user.get_id())
File "/usr/local/lib/python3.6/site-packages/sqlalchemy/orm/query.py", line 3355, in scalar
ret = self.one()
File "/usr/local/lib/python3.6/site-packages/sqlalchemy/orm/query.py", line 3325, in one
ret = self.one_or_none()
File "/usr/local/lib/python3.6/site-packages/sqlalchemy/orm/query.py", line 3294, in one_or_none
ret = list(self)
File "/usr/local/lib/python3.6/site-packages/sqlalchemy/orm/query.py", line 3367, in __iter__
return self._execute_and_instances(context)
File "/usr/local/lib/python3.6/site-packages/sqlalchemy/orm/query.py", line 3392, in _execute_and_instances
result = conn.execute(querycontext.statement, self._params)
File "/usr/local/lib/python3.6/site-packages/sqlalchemy/engine/base.py", line 982, in execute
return meth(self, multiparams, params)
File "/usr/local/lib/python3.6/site-packages/sqlalchemy/sql/elements.py", line 287, in _execute_on_connection
return connection._execute_clauseelement(self, multiparams, params)
File "/usr/local/lib/python3.6/site-packages/sqlalchemy/engine/base.py", line 1101, in _execute_clauseelement
distilled_params,
File "/usr/local/lib/python3.6/site-packages/sqlalchemy/engine/base.py", line 1250, in _execute_context
e, statement, parameters, cursor, context
File "/usr/local/lib/python3.6/site-packages/sqlalchemy/engine/base.py", line 1476, in _handle_dbapi_exception
util.raise_from_cause(sqlalchemy_exception, exc_info)
File "/usr/local/lib/python3.6/site-packages/sqlalchemy/util/compat.py", line 398, in raise_from_cause
reraise(type(exception), exception, tb=exc_tb, cause=cause)
File "/usr/local/lib/python3.6/site-packages/sqlalchemy/util/compat.py", line 152, in reraise
raise value.with_traceback(tb)
File "/usr/local/lib/python3.6/site-packages/sqlalchemy/engine/base.py", line 1246, in _execute_context
cursor, statement, parameters, context
File "/usr/local/lib/python3.6/site-packages/sqlalchemy/engine/default.py", line 581, in do_execute
cursor.execute(statement, parameters)
sqlalchemy.exc.ProgrammingError: (psycopg2.ProgrammingError) relation "user_attribute" does not exist
LINE 2: FROM user_attribute
^

[SQL: SELECT user_attribute.welcome_dashboard_id AS user_attribute_welcome_dashboard_id
FROM user_attribute
WHERE user_attribute.user_id = %(user_id_1)s]
[parameters: {'user_id_1': '1'}]
(Background on this error at: http://sqlalche.me/e/f405)
The debugger caught an exception in your WSGI application. You can now look at the traceback which led to the error.
To switch between the interactive traceback and the plaintext one, you can click on the "Traceback" headline. From the text traceback you can also create a paste of it. For code execution mouse-over the frame you want to debug and click on the console icon on the right side.

You can execute arbitrary Python code in the stack frames and there are some extra helpers available for introspection:

dump() shows all variables in the frame
dump(obj) dumps all that's known about the object

How to reproduce the bug

Run steps mentioned previously.

It is worth noting that when I follow the same steps with the branch 0.36 I do not see this problem. So it must be something that got introduced into the master branch but was not released in 0.36.

Environment

(please complete the following information):

superset version: master branch

python version: based on the docker-compose file

node.js version: based on the docker-compose file

npm version: based on the docker-compose file

Checklist

Make sure these boxes are checked before submitting your issue - thank you!

I have checked the superset logs for python stacktraces and included it here as text if there are any.

I have reproduced the issue with at least the latest released version of superset.

I have checked the issue tracker for the same issue and I haven't found one similar.

Additional context

Add any other context about the problem here.