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

   ### SUMMARY
   
   Draft POC exploring what's needed to build 
[SIP-96](https://github.com/apache/superset/issues/24271) (admin-configurable 
in-app notifications) as a Superset Extension, rather than a core feature.
   
   Researching the current Extensions system turned up three things SIP-96 
needs that don't exist as extension injection points anywhere in the platform 
today:
   1. A way for an extension to show a global toast notification.
   2. A way for an extension to add an entry to the Settings menu / reach a 
full-page screen outside SQL Lab.
   3. (Investigated, not a real gap — see below) A way for an extension to 
register a new RBAC permission.
   
   This PR adds the first two. It turned out smaller than expected: the 
`views`/`menus` registries in 
`superset-frontend/src/core/{views,menus}/index.ts` already take an arbitrary 
`location` string — SQL Lab was just the only *consumer* so far (via 
`src/SqlLab/contributions.ts`'s `ViewLocations` and the reusable 
`<ViewListExtension viewId={location} />` renderer). Nothing SQL-Lab-specific 
lives in the registries themselves.
   
   **What's added:**
   - `ExtensionContext.window` — 
`showInformationMessage`/`showWarningMessage`/`showErrorMessage`, a thin 
wrapper over the existing toast action creators 
(`addInfoToast`/`addWarningToast`/`addDangerToast`). Dispatches directly 
against the app-level `store` singleton rather than via a `useDispatch()` hook, 
since this needs to work from non-component extension code too (e.g. a 
registered command's callback), not just from within a React render.
   - `GlobalLocations.settings.{menu,panel}` (new `src/core/contributions.ts`, 
mirroring `SqlLab/contributions.ts`) — a new views/menus contribution area 
alongside the existing `sqllab.*` ones. `RightMenu.tsx`'s Settings dropdown now 
renders an "Extensions" group from `useMenu(GlobalLocations.settings.menu)`, 
executing the item's registered command on click — this exactly mirrors 
`PanelToolbar`'s existing `commands.getCommand`/`executeCommand` pattern for 
secondary actions, no new pattern invented.
   - A new generic route, `/extensions/view/:viewId` 
(`src/pages/ExtensionView`), hosting a single extension-registered view. Needed 
because `resolveView` is host-internal (`src/core/views/index.ts`), not 
exported through the public `@apache-superset/core` SDK — an extension can 
register a view, but only the host can actually render it, so there needs to be 
*somewhere* for the host to do that rendering outside SQL Lab's own 
panels/status bar.
   
   **On the third gap (RBAC permission registration) — turned out to already 
work, no code needed:** `superset/core/api/core_api_injection.py`'s `add_api()` 
already calls `appbuilder.add_api(api_class)` + 
`appbuilder._add_permission(view, True)`, the exact same real Flask-AppBuilder 
registration path core APIs use. A `@permission_name(...)` on an extension's 
own `@api`-decorated endpoint should already produce a genuine, distinct 
permission visible in the role editor — this just isn't documented/highlighted 
anywhere as an extension capability yet. Worth confirming end-to-end once an 
extension actually exercises it (tracked as follow-up, not blocking this PR).
   
   ### BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
   
   N/A — this PR only adds the injection points; nothing renders differently 
until an extension actually registers something at the new locations.
   
   ### TESTING INSTRUCTIONS
   
   ```bash
   npx jest superset-frontend/src/extensions/ExtensionContext.test.ts 
superset-frontend/src/features/home/RightMenu.test.tsx
   ```
   
   - `ExtensionContext.test.ts`: 4 new cases for `.window` (info/warning/error 
dispatch + lazy-singleton behavior).
   - `RightMenu.test.tsx`: 1 new case registering a real command + menu item 
via the actual `commands`/`menus` registries, rendering `RightMenu`, opening 
the Settings dropdown, and asserting the registered item appears.
   
   Manual: no visible change without a companion extension exercising the new 
surfaces (in progress separately).
   
   ### ADDITIONAL INFORMATION
   
   - [x] Has associated issue: 
[#24271](https://github.com/apache/superset/issues/24271) (SIP-96)
   - [ ] Required feature flags:
   - [ ] Changes UI
   - [ ] Includes DB Migration
   - [ ] Introduces new feature or API
   - [ ] Removes existing feature or API
   
   Opened as a draft to get early signal before going further — happy to open a 
formal SIP if there's contention on the approach. @enzomotta @mistercrunch, 
tagging as the primary drivers of the Extensions system per recent commit 
history, in case there's context I'm missing on why these two surfaces don't 
exist yet.


-- 
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