fix(embedded): adding logic to check dataset used by filters #24808
Conversation
Codecov Report
@@ Coverage Diff @@
## master #24808 +/- ##
===========================================
+ Coverage 58.40% 68.85% +10.44%
===========================================
Files 1902 1903 +1
Lines 73996 74089 +93
Branches 8195 8194 -1
===========================================
+ Hits 43220 51013 +7793
+ Misses 28657 20955 -7702
- Partials 2119 2121 +2
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 222 files with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
superset/security/manager.py
Outdated
| for target in filter_.get("targets", []) | ||
| ] | ||
| if datasource.id in filter_dataset_ids: | ||
| exists = True |
There was a problem hiding this comment.
| exists = True | |
| return True |
We should short circuit when possible.
There was a problem hiding this comment.
Makes perfect sense! Made this change.
superset/security/manager.py
Outdated
| exists = True | ||
| except ValueError: | ||
| pass | ||
|
|
||
| return exists |
| @@ -2063,6 +2064,27 @@ def can_access_based_on_dashboard(datasource: "BaseDatasource") -> bool: | |||
| ) | |||
|
|
|||
| exists = db.session.query(query.exists()).scalar() | |||
|
|
|||
| # check for datasets that are only used by filters | |||
There was a problem hiding this comment.
I think this logic makes sense. The one thing I struggle with regarding this method (for both the existing and proposed logic) is how is agnostic of the specific dashboard in question and thus iterates over all dashboards said user has access to. This raises two questions i) correctness, and ii) efficiency.
Currently I can't formulate a situation where (i) is a problem, however for (ii) this method seems highly inefficient, e.g. we loop over all the dashboards a user has access to in relation to said dataset/datasource, whereas in actuality we likely know the context a priori.
Note in #24789 this method is slated for removal, but the addition of the integration test will ensure that the logic will be preserved.
There was a problem hiding this comment.
@john-bodley I totally agree that this approach is far from ideal from a performance point of view. I think with the bigger changes that are going to be discussed, we can reformulate this process and make sure this validation happens with a target dashboard ID in mind. I saw in #24804 that you have updated the raise_for_access function so it can also receive a dashboard, so I think it would be easier to implement this improvement once those changes (and other decisions made in regards to expected behavior) are made.
Personally this is my second contribution to Superset so I would rather avoid doing bigger estructural changes until I get more familiar with the code as a whole.
|
@john-bodley thanks for the feedback! We'll wait for your approval before merging. |
michael-s-molina
added
the
v3.0
|
🏷️ preset:2023.31 |
…pache#24808)" This reverts commit 7f9b038.
(cherry picked from commit 7f9b038)
…d by filters (apache#24808) (apache#24892)" This reverts commit 9f7f2c6.
mistercrunch
added
🍒 3.0.4
🏷️ bot
SUMMARY
When granting dashboard access to a guest user, it's only granted access to datasets used by its charts. If the dashboard has any native filters powered by datasets that aren't used by any chart, the filter wouldn't load with a permission error. This PR changes this logic to also allow access to datasets used by filters.
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
Before
After
TESTING INSTRUCTIONS
select * ...would be enough).guest_tokenand grant access to this dashboard.ADDITIONAL INFORMATION
EMBEDDED_SUPERSET = True