-
Notifications
You must be signed in to change notification settings - Fork 14k
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
refactor: Removes the Filter Box code #26328
refactor: Removes the Filter Box code #26328
Conversation
@michael-s-molina thanks for tackling this. I think there's more dead code which could be removed, i.e., the changeFilter logic seems to be filter-box related. I also suspect that the entirety of dashboardFilters.js et al. could be removed. |
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #26328 +/- ##
==========================================
+ Coverage 69.28% 69.57% +0.28%
==========================================
Files 1909 1893 -16
Lines 74875 74220 -655
Branches 8398 8263 -135
==========================================
- Hits 51876 51635 -241
+ Misses 20856 20504 -352
+ Partials 2143 2081 -62
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
@john-bodley I also thought this was related but in fact it's used by the feature that shows which filters are applied to a chart. |
@michael-s-molina I also thought that, however the |
You're correct. The
The |
@john-bodley Screen.Recording.2023-12-29.at.08.33.29.mov |
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
@michael-s-molina both this PR and #26329 handle aspects of removing filter-box charts in favor of the native dashboard filters. These PRs seem highly coupled and per my comments in the later I wonder if there's any incentive to combine them and/or (for review purposes) make one PR are precursor (base branch) of the other? Additionally, though necessary, I don't believe these two PRs are sufficient for the removal of the legacy filter box charts, i.e., a migration is necessary. The native filter CLI commands should provide the necessary logic which (thankfully) has no dependencies on any of the changes outlined in these two PRs. I'm not sure where best to add this, be it in a separate PR, or including with the proposed logic if combined into a single PR, but it seems there should be an Alembic migration added where the upgrade is akin to: from superset.cli import native_filters
def upgrade() -> None:
native_filters.upgrade(["--all"], standalone_mode=False)
native_filters.cleanup(["--all"], standalone_mode=False)
def downgrade() -> None:
pass |
Although related, the features work independently of each other which allow us to have separate PRs. Having said that, pretty much any 4.0 PR will need to be rebased once another one is merged to master given the number of touched files in these types of PRs. In other words, if we merge the native filters one first, this one will need to be rebased and vice versa. |
I added a migration script to forcefully migrate legacy filter boxes. I copied the logic from the CLI command into the migration file and made the adjustments such as binding the session and using pagination. This allows us to encapsulate filter box dependencies inside a migration script and remove the CLI command. |
9e4d575
to
fa7ab9c
Compare
@michael-s-molina regarding,
There's still the need to cleanup the dashboard metadata (the temporary fields allows one to downgrade) as well as removal of the filter box charts. I'm not sure if it makes more sense to make this migration either:
If we opt for the later, the issue is that the cleanup logic no longer exists. My sense is we will need to preserve the |
@@ -192,7 +191,6 @@ | |||
"react-reverse-portal": "^2.1.1", | |||
"react-router-dom": "^5.3.4", | |||
"react-search-input": "^0.11.3", | |||
"react-select": "^3.2.0", |
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.
YAAAAAAAAAAAAYYYYY!!!!
@@ -542,9 +542,11 @@ def test_import_override_dashboard_slice_reset_ownership(self): | |||
self.assertEqual(imported_slc.owners, [gamma_user]) | |||
|
|||
# re-import with another user shouldn't change the permissions | |||
g.user = admin_user |
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.
@michael-s-molina I don't believe your logic is correct, i.e., the original logic was actually correct. The intention of the test (as far as I can tell) is to import a dashboard into Superset (as the gamma
user) and then reimport the same dashboard (as the admin
user). Given that the dashboard existed the creator and owner should not change.
I presume the changed_by
doesn't change because none of the dashboard attributes (metadata) changed, but that's simply a hunch.
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.
Let me know how you want to proceed here. I assumed the tests were similar because they have the exact names with the only difference being new vs override. Given that you wanted to skip the test, I would keep it as is.
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.
@michael-s-molina I wonder if we should leave the test as-is and just skip it. It's the legacy version of the importer as well and thus it's likely unused. Maybe @betodealmeida would have some thoughts regarding this?
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.
Yeah, it's a common pattern, where admins will manage dashboards under source control and periodically sync them to Superset. In that case you want to preserve the original ownership.
But like John said, if this is for the v0 importer (I'm on my phone, hard to see) then I wouldn't worry about it too much, since a lot of the behavior there is not strictly defined.
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.
@john-bodley I reverted and skipped the test.
7a69b1a
to
a098249
Compare
a098249
to
37d3340
Compare
* Formerly called "filters", which was misleading because it is actually | ||
* initial values of the filter_box and table vis | ||
*/ | ||
/** Initial values */ |
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.
Nit: maybe we should just remove this comment?
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.
Removed!
@@ -47,7 +47,7 @@ const TelemetryPixel = ({ | |||
const pixelPath = `https://apachesuperset.gateway.scarf.sh/pixel/${PIXEL_ID}/${version}/${sha}/${build}`; | |||
return process.env.SCARF_ANALYTICS === 'false' ? null : ( | |||
<img | |||
referrerPolicy="no-referrer-when-downgrade" | |||
referrerPolicy="no-referrer" |
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.
Is this change related to the pr or just a rebase mistake?
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.
It was a rebase mistake! Reverted!
@@ -581,7 +581,7 @@ export function addSliceToDashboard(id, component) { | |||
]).then(() => { | |||
dispatch(addSlice(selectedSlice)); | |||
|
|||
if (selectedSlice && selectedSlice.viz_type === 'filter_box') { | |||
if (selectedSlice) { |
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 the code in the if
block was meant to run only for filter box, shouldn’t we remove it?
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.
Great call! By removing this I was able to remove even more code!
@@ -591,7 +591,7 @@ export function addSliceToDashboard(id, component) { | |||
export function removeSliceFromDashboard(id) { | |||
return (dispatch, getState) => { | |||
const sliceEntity = getState().sliceEntities.slices[id]; | |||
if (sliceEntity && sliceEntity.viz_type === 'filter_box') { | |||
if (sliceEntity) { |
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.
Same as above
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.
Removed!
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.
Amazing work! LGTM
Co-authored-by: John Bodley <[email protected]>
Co-authored-by: John Bodley <[email protected]>
SUMMARY
As part of the 4.0 approved initiatives, this PR removes the Filter Box code and it's associated dependencies
react-select
andarray-move
. It also removes theDeprecatedSelect
andAsyncSelect
components that were exclusively used by filter boxes. Existing filter boxes will be automatically migrated to native filters.TESTING INSTRUCTIONS
CI should be sufficient for merging this PR. We'll do a complete testing of 4.0 after all approved proposals are merged.
ADDITIONAL INFORMATION