villebro opened a new pull request, #41897: URL: https://github.com/apache/superset/pull/41897
### SUMMARY The subject-based access control feature stores "subjects" — a unified table that represents each User, Role, and Group as a single entity with its own id. Until now these were only visible through an admin-only **"Subjects"** page under Settings → Security, and there was no programmatic way to look them up. The main motivation for a real API is **id mapping**: given a user, role, or group id, callers (and extensions) need to find the corresponding subject entity, and vice versa. This PR adds that, removes the technical admin page, and fills in some gaps in the extensions framework along the way. New API resource/endpoints: <img width="1158" height="236" alt="image" src="https://github.com/user-attachments/assets/423e52f4-a945-431e-a7c5-43289aa658f1"; /> **What this PR does:** - **Adds a read-only Subject REST API** (`GET /api/v1/subject/`). - Lists subjects and supports lookups by any field — importantly, you can filter by `user_id`, `role_id`, or `group_id` to resolve the subject for a specific principal (e.g. `GET /api/v1/subject/?q=(filters:!((col:user_id,opr:eq,value:5)))`), plus filter by `type`, `active`, and free-text search on the label. - Responses use flat scalar ids (`"user_id": 5`, `"group_id": 2`) rather than nested objects, which is what id-matching callers actually want. - **Read-only by design**: only `GET` / list / info are exposed — no create/update/delete — because subjects are derived automatically from users/roles/groups and kept in sync via hooks. - **Permissions**: the API is gated by a dedicated `Subject` permission, which is granted to **Admins only** by default. Non-admins receive `403`. (Subjects enumerate all users/roles/groups, so this is intentionally restricted.) It is registered unconditionally and no longer tied to the `ENABLE_VIEWERS` flag. - **Removes the "Subjects" admin menu page**, since it was an internal technical detail that shouldn't be surfaced in the UI. The data is now available through the API instead. - **Adds a `SubjectDAO`** and, more broadly, **backfills missing entries in the extensions framework**. The abstract models and DAOs exposed to extensions were missing not just `Subject`, but also `User` and `Group` — so this PR adds abstract models + DAOs for **`Subject`, `User`, and `Group`** (Role and its DAO were already present), and wires the real host implementations in. This lets extension authors work with these entities the same way they already can with datasets, dashboards, charts, etc. - **Internal cleanup**: the subject-sync helpers now go through `SubjectDAO` instead of hand-written queries, with no change to transactional behavior. ### TESTING INSTRUCTIONS 1. As an Admin, hit `GET /api/v1/subject/` → returns the subject list. 2. Resolve a subject by principal id, e.g. `GET /api/v1/subject/?q=(filters:!((col:user_id,opr:eq,value:1)))`; also try `type` (`opr:eq`) and the `subject_all_text` filter on `label`. 3. Confirm responses contain flat `user_id` / `role_id` / `group_id`. 4. `GET /api/v1/subject/_info` shows only `can_read`; a non-admin (e.g. Gamma) gets `403`; `POST` / `PUT` / `DELETE` return `405`. 5. Confirm the **"Subjects"** entry is gone from Settings → Security. 6. From an extension / shell: `from superset_core.common.daos import SubjectDAO, UserDAO, GroupDAO` and `SubjectDAO.find_all()` works. 7. Tests: pytest tests/unit_tests/dao/subject_test.py tests/unit_tests/subjects/ pytest tests/integration_tests/subjects/api_tests.py # requires integration DB -- 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]
