## Description
**Targets main.** This is the first of four cleanup PRs (#16240, #16241,
#16242, #16243) that fix the design-system violations that #16234
(merged) put in the warn-only baseline. This PR replaces `lucide-react`
and `react-icons` with `@opal/icons`.
### Before and after
10 files imported `lucide-react` (3) or `react-icons` (7). This PR
migrates them all, except for 3 icons that have no Opal match. Three
files are now clean of the design-system rules, so they are removed from
the baseline in `web/.oxlintrc.json`:
- `src/app/admin/agents/CollapsibleSection.tsx`
- `src/app/app/message/messageComponents/interfaces.ts`
- `src/views/admin/connectors/FederatedDetailPage/index.tsx`
### Changes (all under `web/src/`)
| File | Old | New |
| --- | --- | --- |
| `app/admin/agents/CollapsibleSection.tsx` | `FiSettings` |
`SvgSettings` (size 16 kept) |
| `app/admin/bots/[bot-id]/channels/SlackChannelConfigFormFields.tsx` |
lucide `AlertCircle` | `SvgAlertCircle` (classes kept) |
| `app/admin/documents/feedback/DocumentFeedbackTable.tsx` | `FiEye`,
`FiEyeOff` | `SvgEye`, `SvgEyeOff` |
| `app/admin/documents/sets/page.tsx` | `FiCheckCircle`, `FiClock`,
`FiAlertTriangle`, `FiLock`, `FiEdit2` | The matching `Svg*` icons;
`FiEdit2` becomes `SvgEdit` |
| `app/app/message/errorHelpers.tsx` | lucide `AlertCircle`, `Clock`,
`Lock`, `Server` | The matching `Svg*` icons |
| `app/app/message/messageComponents/interfaces.ts` | `IconType` from
`react-icons` | `IconFunctionComponent \| null`. No caller passes a
react-icons icon any more |
| `app/app/message/messageComponents/toolDisplayHelpers.tsx` | `FiTool`,
`FiCircle` | `SvgWrench`, `SvgCircle` |
| `app/ee/admin/performance/query-history/[id]/page.tsx` | `FiBook` |
`SvgBook` |
| `app/ee/admin/standard-answer/page.tsx` | `FiTag` | `SvgTag` (size 16)
|
| `views/admin/connectors/FederatedDetailPage/index.tsx` | lucide
`Loader2` | `SvgLoader` (classes kept) |
### Kept on purpose (no matching Opal icon)
These sites still trip the rule and stay in the baseline. Each needs an
icon added to `web/lib/opal/src/icons/` from Figma first:
- `Wifi` in `errorHelpers.tsx`: Opal has no wifi or signal icon.
- `FiUnlock` in `documents/sets/page.tsx`: Opal has `lock` but no unlock
icon. The lock and unlock icons in that table now come from different
sets.
- `FiList` in `toolDisplayHelpers.tsx`: no Opal icon has the same
bullet-list shape (`list-tree`, `list-check` and `text-lines` all
differ).
### Visual differences reviewers should check
- **Size:** react-icons default to `1em`, but Opal icons have no default
size, so I set an explicit size from the text size around each icon:
- `SvgEye`/`SvgEyeOff` are 12 (they sit in `text-xs`).
- `SvgBook` is 14 (it sits in `text-sm`).
- `SvgEdit` is 16. Its button sets no text size, so this one is a guess.
- **Stroke:** lucide icons use stroke width 2, and Opal icons use 1.5,
so lines look slightly thinner.
- **`FiEdit2` to `SvgEdit`:** Opal's pencil has an underline.
- **`FiCircle` to `SvgCircle`:** the Opal circle is smaller (r=4 in a 16
box, where the old one was r=10 in a 24 box). It is only the fallback
when there are no packets, and `ReasoningRenderer` already uses
`SvgCircle`.
## How Has This Been Tested?
- oxlint: in the changed files, only the 3 icons listed above still
report. The full run has 0 errors.
- `bun run types:check`: no type errors, and type coverage stays at
99.04%.
- pre-commit (oxfmt, oxlint) passes on the changed files.
## Additional Options
- [ ] [Optional] Please cherry-pick this PR to the latest release
version.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Style**
* Updated icons across admin pages, document controls, chat tools, and
message error states for a more consistent appearance.
* Loading indicators, visibility controls, and error-state behavior
remain unchanged.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Description
Use one decision endpoint for Approve once, Approve for session, and
Reject. Concurrent session approvals lock the session before updating
requests to prevent conflicting lock order.
Keep approval outcomes available after decisions and reloads as compact,
neutral conversation rows. Details start collapsed. Expired rows state
that the action did not run; only pending requests show an attention
border and decision buttons. The server decides whether a request is
still live; a user's device clock cannot disable it. History includes
live requests and the 50 most recent outcomes. Polls read small status
records and refresh full history when statuses change.
The proxy still waits up to 180 seconds. This is a network wait, not
durable paused execution. Expired requests show Expired, and late
decisions return a conflict. Agent permission requests that cannot
resume fail scheduled runs with a clear reason. Losing an execution
lease aborts the agent.
The plugin editors and personal/task permission controls are in the
preceding PR, #16185. Approval queries remain in the existing Craft DB
module, as requested for this feature.
## How Has This Been Tested?
- Ten approval-card/history tests pass, including collapsed neutral
expiry, detail expansion, and live-request controls.
- A browser check confirmed the neutral expired row and unchanged
pending controls.
- 82 gate unit tests passed after restoring the Craft DB module.
- Earlier verification passed 21 approval API database tests, including
concurrent session grants, retries, conflicting decisions, history, and
expiry.
- Earlier local Kind checks covered concurrent grants, a browser clock
ten minutes ahead, and approved history after reload.
- A scheduled worker requested approval without an open browser;
approval resumed execution and produced the expected result.
- An actual 180-second timeout blocked forwarding and rejected a late
decision.
- Follow-up verification passed 39 approval/executor database tests, 550
proxy unit tests, and five route-contract tests.
## Additional Options
- [ ] [Optional] Please cherry-pick this PR to the latest release
version.
- [x] [Optional] Override Linear Check
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Approval cards now offer **Approve once**, **Approve for session**,
and **Reject** in one flow, with session-wide approval available when
eligible.
* Session approval history now shows pending, approved, rejected, and
expired requests. Status updates are checked automatically, and changed
statuses refresh the history.
* Cards show approval deadlines and present completed requests as
compact, expandable outcomes.
* **Bug Fixes**
* Scheduled runs that need unavailable permissions now finish as failed
runs instead of waiting for approval.
* Expired approval messages clarify that the action did not run.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Description
Give each user and scheduled task its own action settings.
Workspace-disabled actions always remain blocked. Admins can require
workspace settings or let users choose their own settings.
Scheduled tasks now show app and MCP cards. Apps start disabled. When
creating a task, enabling an app copies the user's current settings.
Existing tasks keep their saved choices when apps are enabled again;
missing choices require approval. Later requests use the task's saved
settings and current workspace restrictions.
One migration replaces app-wide task pre-approvals with per-action
settings. Existing tasks receive auto-approval only for known actions in
apps they already pre-approved. Apps remain enabled even if they have no
known actions. New actions require approval. The migration remains with
the code that reads the new tables.
Action recognition identifies the request. One policy resolver then
applies workspace restrictions, task membership, personal or task
settings, and session grants. Failed recognition or policy lookup blocks
the request. A completed scheduled session cannot use personal settings
for later requests.
The next PR adds app settings editors. This PR includes the task editor
because its payload changes with the task API.
## How Has This Been Tested?
The complete stack passed 71 local Kind scenario checks, covering
browser editing, persistence, access restrictions, real proxy requests,
and scheduled execution. Checks include a real 180-second approval
timeout, live policy changes, and completed-task request rejection.
This PR’s intermediate tree passed 1,053 backend unit tests, 148
database tests, five route-contract tests, and 39 frontend tests. Python
and TypeScript checks and changed-file pre-commit checks passed.
No migration was applied to the user's database during this
verification.
## Additional Options
- [ ] [Optional] Please cherry-pick this PR to the latest release
version.
- [x] [Optional] Override Linear Check
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added per-action approval settings for connected apps and MCP tools,
with workspace, personal, and scheduled-task controls.
* Scheduled tasks can enable apps and configure individual actions when
creating or editing tasks; settings are also visible on task details.
New tasks start with apps disabled.
* Policy editors support searching, bulk changes, and resetting editable
choices.
* **Security & Permissions**
* Workspace restrictions remain binding, and task settings are checked
during active runs.
* Actions requiring approval still prompt users when app credentials are
unavailable.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->