feat(permissions): Adding the permission shield overlay to Sistent base components

[rishiraj38]

What this does

This adds permission awareness to Sistent's base components (Button, IconButton, ListItem, ListItemButton, MenuItem) so that consumer apps like Meshery can show users why something is disabled instead of just graying it out with no explanation.

The approach is intentionally simple; Sistent doesn't try to own the permission-checking logic. That stays in the consumer app where it belongs (via their existing CAN() function). Sistent just handles the visual side:

If a component is disabled and a permissionKey prop is provided → wrap it in a PermissionShield that shows a lock icon with details about the blocked action on click.

What's included

• PermissionShield (src/custom/permissions.tsx) -- A visual wrapper component that grays out its children and overlays a shield/lock icon. Clicking the icon shows a styled tooltip with permission metadata (category, subcategory, blocked action, description, resource ID). Uses ClickAwayListener and a custom event to ensure only one tooltip is open at a time.

• Updated base components -- Button, IconButton, ListItem, ListItemButton, and MenuItem now accept optional permissionKey props. When disabled with a key present, they automatically render inside PermissionShield.

• Backward-compatible Key type -- Supports both the existing action/subject schema and the newer id/function/category/subcategory/description schema. The createCanShow helper was also updated to handle both.

• Exports -- PermissionShield, Key, and PermissionShieldProps are exported from src/index.tsx.

How to use it

// The consumer app still owns the permission check — Sistent just shows the UI
<IconButton
  disabled={!CAN(Keys.CatalogManagementEditDesign.id, Keys.CatalogManagementEditDesign.function)}
  permissionKey={Keys.CatalogManagementEditDesign}
>
  <EditIcon />
</IconButton>

That's it. No providers, no context, no hooks. The permissionKey metadata (category, description, etc.) powers the tooltip content automatically.

Why this approach

I wanted to keep Sistent as a pure UI library here. Permission logic varies between consumer apps; some use CASL, some use custom RBAC, some hit an API. Baking any of that into Sistent would couple it to a specific implementation. Instead, the consumer decides disabled={true/false} and Sistent just makes the disabled state informative rather than a dead end for the user.

MockUps

Screen.Recording.2026-07-08.at.6.02.10.PM.mov

Signed commits

• Yes, I signed my commits.

[rishiraj38]

This is just a mockup to validate the implementation. I'll handle the formatting afterward, including the tooltip content, colors, and the permission shield icon.

[rishiraj38]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces a new PermissionShield wrapper component to display permission metadata overlays on disabled base components (Button, IconButton, ListItem, ListItemButton, and MenuItem) when a permissionKey is provided. Feedback on these changes highlights a bug in ListItem where the disabled prop is not forwarded to the underlying component, potential runtime crashes in PermissionShield and createCanShow due to missing guards for permissionKey and children validity, and a recommendation to expose hardcoded UI strings as props to support internationalization.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.