rusackas opened a new pull request, #42590:
URL: https://github.com/apache/superset/pull/42590

   ### SUMMARY
   
   This is a **test-only PR** opened as a TDD-style validation of issue #39296.
   
   #39296 (filed 2026-04) reports that a user without "all datasource access" 
gets blocked clicking "Create Chart" straight from a SQL Lab query, even though 
they just ran that exact query, and that the only workaround is SQL Lab → Save 
dataset → Create chart. Dosubot's analysis on the issue frames this as a 
missing-owner problem, but reading the actual code 
(`superset/commands/explore/form_data/create.py`, `superset/explore/utils.py`, 
`superset/security/manager.py`), the temp explore state *does* record an 
`owner`, it's just never consulted: the QUERY-type access path 
(`check_query_access` → `raise_for_access(query=...)`) only ever checks 
catalog/schema/dataset-level `datasource_access`, with no "you authored this" 
bypass. The TABLE path (saved datasets) *does* have one, via 
`is_editor`/ownership. That asymmetry, not a missing field, is the actual bug 
shape.
   
   Dosubot also names three PRs (#38647, #38952, #37185) merged since filing 
that touched adjacent parts of this permission surface; none of them add an 
authorship bypass to the QUERY path, they tighten/centralize existing checks, 
so this looked unlikely to already be fixed.
   
   This PR adds one regression test on `superset/explore/utils.py`:
   
   1. **`test_unsaved_query_explore_has_no_query_authorship_bypass`** — asserts 
that `check_access(datasource_id=..., chart_id=None, 
datasource_type=DatasourceType.QUERY)` denies a user who has no 
catalog/schema/dataset-level `datasource_access`, mirroring the existing 
`test_query_no_access` but through the actual `check_access` entry point 
`CreateFormDataCommand` calls for the "Create Chart" button (rather than the 
lower-level `check_datasource_access` that test already covers), with 
`chart_id=None` matching a brand-new, not-yet-saved explore.
   
   ### How to interpret CI
   
   - **CI green** → confirms the current behavior: no authorship bypass on the 
QUERY path. This isn't a crash/regression, it's the intentional-looking (if 
confusing) permission model the issue is reacting to. A green result here means 
the "fix" is a product/UX decision (add an authorship bypass? point users at a 
clearer error message?), not a broken-contract bug.
   - **CI red** → something changed and the QUERY path now denies differently 
than expected; worth a second look before assuming the asymmetry is gone.
   
   ### TESTING INSTRUCTIONS
   
   ```bash
   pytest 
tests/unit_tests/explore/utils_test.py::test_unsaved_query_explore_has_no_query_authorship_bypass
 -v
   ```
   
   ### ADDITIONAL INFORMATION
   
   - [x] Has associated issue: closes #39296
   - [ ] Required feature flags:
   - [ ] Changes UI
   - [ ] Includes DB Migration
   - [ ] Introduces new feature or API
   - [ ] Removes existing feature or API
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to