Feature flagging moved over to redesign

[corypride]

Description of the change

Ports the Feature Control (feature flagging) admin page from the original frontend to the redesign. System admins can now toggle platform-wide features on and off directly from the redesigned UI.

Changes include:

• New FeatureControl.tsx page under /feature-control, accessible only to SystemAdmin role

• Toggle support for top-level features (Knowledge Center, Program Hub & Tracking) and Knowledge Center sub-features (Request Content Button, Helpful Links, Videos)

• Confirmation dialog before applying any toggle, with a statewide impact warning when disabling resident-facing features

• Sub-features are visually disabled (opacity + Switch disabled) when their parent feature is off

• "Feature Control" nav link added to Sidebar.tsx admin nav, visible only to system admins, using AdjustmentsHorizontalIcon

• systemAdminRoutes route group added to app-routes.tsx gating the route to UserRole.SystemAdmin

• Related issues: https://app.asana.com/1/1201607307149189/project/1209460078641109/task/1214641676425184

Screenshot(s)

Additional context

The API calls (PUT auth/features/:key and PUT auth/page-features/:key) were already in place from the original frontend — this commit only brings the UI into the redesign. No backend changes were made.

[coderabbitai]

📝 Walkthrough

Walkthrough

This PR adds FeatureControl.tsx, a new admin page for managing feature access toggles. The component reads the authenticated user, derives enabled states, and provides UI to toggle features with confirmation dialogs. On confirmation, it issues API requests to update access, refreshes user state, and emits success/error notifications. Sub-features can be disabled when their parent is off.

Changes

Feature Control Admin Page

Layer / File(s)	Summary
Type definitions and state shape frontend/src/pages/admin/FeatureControl.tsx	Local types define toggle targets (feature vs page-feature) and a PendingToggle state object carrying the target, display label, and desired next boolean value.
State management and API handlers frontend/src/pages/admin/FeatureControl.tsx	FeatureControl component derives enabled flags from user.feature_access, defines requestToggle to store pending intent, and defines async confirmToggle that performs API update via API.put, refreshes user via fetchUser, emits toasts, and manages loading state.
Main UI rendering and confirmation dialog frontend/src/pages/admin/FeatureControl.tsx	Renders feature toggles including "Knowledge Center" parent switch with dependent sub-feature rows and "Program Hub & Tracking" section. Confirmation Dialog driven by pending state shows dynamic enable/disable messaging, disabling warnings, and wired Cancel/Confirm buttons.
SubFeatureRow component frontend/src/pages/admin/FeatureControl.tsx	Reusable presentational component rendering a labeled toggle with description, visually dimmed and disabled when parentEnabled is false to enforce parent-child feature dependencies.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarizes the main change: porting the feature flagging admin page from the original frontend to the redesigned UI.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description check	✅ Passed	The pull request description clearly explains that it ports the Feature Control admin page from the original frontend to the redesign, including specific features like toggle support, confirmation dialogs, navigation updates, and routing restrictions.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@frontend/src/pages/admin/FeatureControl.tsx`:
- Around line 48-67: handleConfirm currently sends a toggle because the API.put
call omits the desired state; change the request to send the intended state
(e.g., include { enabled: newValue } or similar payload) when calling API.put
for `auth/${urlSegment}/${target.key}`, then read the server-confirmed state
from the response (or re-fetch via fetchUser) and use that server-confirmed
value when calling setUser, setPending(null) and when composing toast
success/error messages so the UI reflects the server-side state rather than
assuming newValue.
- Around line 97-106: The Switch controls (e.g., the Switch component instance
that uses checked={kcEnabled} and onCheckedChange={()=>requestToggle({ type:
'feature', key: FeatureAccess.OpenContentAccess }, 'Knowledge Center',
kcEnabled)}) lack accessible names; add an aria-label or aria-labelledby prop to
each Switch (including the other instances for sub-features referenced) with a
clear, unique label such as "Toggle Knowledge Center feature" (or the
appropriate sub-feature name) so screen readers can identify them; update every
Switch usage in this component to include the prop while keeping existing
checked and onCheckedChange handlers.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: b3cb8218-7393-4873-a7df-784304b1c8d0

📥 Commits

Reviewing files that changed from the base of the PR and between edf64e4 and c52e1af.

📒 Files selected for processing (1)

• frontend/src/pages/admin/FeatureControl.tsx

[coderabbitai]

⚠️ Potential issue | 🔴 Critical | 🏗️ Heavy lift

Make this write idempotent; current toggle flow can apply the opposite state.

Line 55 sends no desired value, so this behaves like a toggle operation. Combined with retries/transient errors/concurrent admins, a second confirmation can flip the feature back while Line 65 still reports the client-intended state. Please move to a set-state contract (e.g., send enabled: newValue and use server-confirmed state in UI messaging).

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@frontend/src/pages/admin/FeatureControl.tsx` around lines 48 - 67,
handleConfirm currently sends a toggle because the API.put call omits the
desired state; change the request to send the intended state (e.g., include {
enabled: newValue } or similar payload) when calling API.put for
`auth/${urlSegment}/${target.key}`, then read the server-confirmed state from
the response (or re-fetch via fetchUser) and use that server-confirmed value
when calling setUser, setPending(null) and when composing toast success/error
messages so the UI reflects the server-side state rather than assuming newValue.

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Add accessible names to all Switch controls.

These switches do not expose an explicit accessible name, which makes them ambiguous in screen readers. Add aria-label (or aria-labelledby) for each control, including sub-features.

Suggested patch

                         <Switch
+                            aria-label="Toggle Knowledge Center"
                             checked={kcEnabled}
                             onCheckedChange={() =>
                                 requestToggle(
@@
                         <Switch
+                            aria-label="Toggle Program Hub & Tracking"
                             checked={isEnabled(FeatureAccess.ProgramAccess)}
                             onCheckedChange={() =>
                                 requestToggle(
@@
             <Switch
+                aria-label={`Toggle ${label}`}
                 checked={enabled}
                 onCheckedChange={onToggle}
                 disabled={!parentEnabled}
             />

Also applies to: 170-179, 274-278

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@frontend/src/pages/admin/FeatureControl.tsx` around lines 97 - 106, The
Switch controls (e.g., the Switch component instance that uses
checked={kcEnabled} and onCheckedChange={()=>requestToggle({ type: 'feature',
key: FeatureAccess.OpenContentAccess }, 'Knowledge Center', kcEnabled)}) lack
accessible names; add an aria-label or aria-labelledby prop to each Switch
(including the other instances for sub-features referenced) with a clear, unique
label such as "Toggle Knowledge Center feature" (or the appropriate sub-feature
name) so screen readers can identify them; update every Switch usage in this
component to include the prop while keeping existing checked and onCheckedChange
handlers.