Wenxi
e9c36400a7
## 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 -->
This is a Next.js project bootstrapped with create-next-app.
Getting Started
Install bun: https://bun.sh/docs/installation
Install all dependencies: bun install.
Then, run the development server:
bun run dev
Open http://localhost:3000 with your browser to see the result.
Note: if you are having problems accessing the ^, try setting the WEB_DOMAIN env variable to
http://127.0.0.1:3000 and accessing it there.
Tip
Packages are installed automatically when switching branches after
package.jsonchanges with pre-commit configured.
Connecting to a Cloud Backend
To test your local frontend development server against a cloud backend (e.g., staging or production),
create a .env.local file in the web/ directory with the following configuration:
# Point local dev server to cloud backend
INTERNAL_URL=https://st-dev.onyx.app/api
# Debug auth cookie for authenticating against remote backend
# This cookie is automatically injected into API requests when in development mode
# To get this value:
# 1. Go to https://st-dev.onyx.app (or your target backend URL) and log in
# 2. Open DevTools (F12) → Application → Cookies → [your backend domain]
# 3. Find the "fastapiusersauth" cookie and copy its value
# 4. Paste the value below (without quotes)
# Note: This cookie may expire, so you may need to refresh it periodically
DEBUG_AUTH_COOKIE=your_cookie_value_here
By default, this does NOT override existing cookies, so if you've logged in previously, you
may need to delete the cookies for the localhost domain.
Important notes:
- The
.env.localfile should be created in theweb/directory (same level aspackage.json) - After creating or modifying
.env.local, restart your development server for changes to take effect - The
DEBUG_AUTH_COOKIEis only used in development mode (NODE_ENV=development) - If
INTERNAL_URLis not set, the frontend will connect to the local backend athttp://127.0.0.1:8080 - Keep your
.env.localfile secure and never commit it to version control (it should already be in.gitignore)
Testing
This testing process will reset your application into a clean state. Don't run these tests if you don't want to do this!
Bring up the entire application.
- Install playwright dependencies (run
bun installfirst sobunxresolves to the repo-pinned Playwright innode_modulesinstead of fetching the latest version)
bun install
bunx playwright install
- Run playwright (the
playwrightscript expands toplaywright test)
bun run playwright
To run a single test:
bun run playwright landing-page.spec.ts
If running locally, interactive options can help you see exactly what is happening in the test.
bun run playwright --ui
bun run playwright --headed
- Inspect results
By default, playwright.config.ts is configured to output the results to:
web/output/playwright/
- Visual regression screenshots
Screenshots are captured automatically during test runs and saved to web/output/screenshots/.
To compare screenshots across CI runs, use:
ods screenshot-diff compare --project admin
For more information, see tools/ods/README.md.