-
Notifications
You must be signed in to change notification settings - Fork 14.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(api): unable to delete virtual dataset, wrong permission name #11019
Conversation
if not view_menu: | ||
logger.error( | ||
"Could not find the data access permission for the dataset" | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If a dataset permission does not exist, log the error and delete anyway
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Codecov Report
@@ Coverage Diff @@
## master #11019 +/- ##
==========================================
- Coverage 65.76% 61.35% -4.41%
==========================================
Files 816 817 +1
Lines 38381 38523 +142
Branches 3606 3621 +15
==========================================
- Hits 25240 23637 -1603
- Misses 13033 14700 +1667
- Partials 108 186 +78
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
and replaces them with the current (correct) permission name | ||
""" | ||
from flask_appbuilder.security.sqla.models import ( | ||
ViewMenu, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we be referencing concrete model classes in migrations? This migration will likely fail to run in the future should any of their structure change. Ideally, partial impl's, or copies should be defined directly in the migration in order to avoid such a situation. The other option is to roll all of these migrations up into a subset of what we currently have.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, I'll probably go for the model copy
superset/migrations/versions/3fbbc6e8d654_fix_data_access_permissions_for_virtual_.py
Outdated
Show resolved
Hide resolved
…issions_for_virtual_.py Co-authored-by: Ville Brofeldt <[email protected]>
…ache#11019) * fix(api): unable to delete virtual dataset because of wrong permission name * Still delete the dataset even when no permission was found * migration script to fix possible existing faulty permissions on the db * black * fix db migration and one more test * add more comments to the migration script * freeze a partial schema of the model on the migration step * fix mig script * Update superset/migrations/versions/3fbbc6e8d654_fix_data_access_permissions_for_virtual_.py Co-authored-by: Ville Brofeldt <[email protected]> Co-authored-by: Ville Brofeldt <[email protected]>
SUMMARY
When creating a virtual dataset using SQLLab -> Explorer the call to
superset/sqllab_viz
creates a newSqlaTable
withdatabase_id
set, notdatabase
. This causes a problem on the SQLAlchemy listener that creates/updates permissions on insert/update. Because thedatabase
relation is not set yet at this time theget_perm()
method on the SqlaTable return a permission with[None].[<VIRTUAL DS NAME>](id:22)
instead of[examples].[<VIRTUAL_DS_NAME>](id:22)
When deleting the new dataset delete command will check if the permission for the dataset exists (to delete it also) and this sanity check failed, refusing to delete the dataset. We will delete the dataset and just log an error on this PR.
Also added a migration revision that does its best on fixing any existing faulty data access permissions.
ADDITIONAL INFORMATION