Files

long-agent 9b1cea246e feat: permissions CRUD browser integration + E2E enhancements

Backend:
- permission_handler: 完善权限 CRUD 接口（列表/创建/更新/删除）
- auth_handler: 修复认证处理逻辑
- router: 新增权限管理路由
- handler_test: 新增权限 handler 测试覆盖

Frontend:
- permissions.ts/test.ts: 权限服务层完整实现
- profile/settings/service_tests: 服务适配器修正
- client.ts: HTTP 客户端健壮性增强
- vite.config.js: 构建配置优化
- E2E 脚本: run-playwright-cdp-e2e 大幅增强（权限流程覆盖）

Docs:
- REAL_PROJECT_STATUS: 状态更新
- PRODUCTION_CHECKLIST/QUALITY_STANDARD/TECHNICAL_GUIDE/PROJECT_EXPERIENCE_SUMMARY: 团队规范完善
- plans/2026-04-23: 权限浏览器 CRUD 设计方案

验证: go build 0错误

2026-04-24 07:30:18 +08:00

2.7 KiB

Raw Blame History

Permissions Browser CRUD Design

Date: 2026-04-23

Goal: Extend the supported Playwright CDP browser gate so the admin PermissionsPage is covered by a real CRUD scenario instead of remaining outside the main browser acceptance path.

Scope

Add one new supported browser scenario: permissions-management-crud.
Cover real admin login, permissions page load, top-level permission creation, child permission creation, list/tree verification, edit, status toggle, and delete.
Reuse the existing supported runner frontend/admin/scripts/run-playwright-cdp-e2e.mjs.
Keep selector strategy aligned with current team rules: prefer route, heading, role, label, and scoped containers over broad text scans.

Non-Goals

No redesign of the permissions page UI.
No new backend permissions model behavior beyond what the existing page and APIs already expose.
No expansion into OS-level automation or unsupported browser tooling.

Approach

Treat the new browser scenario as the primary verification surface.
If the scenario exposes a product defect, add the smallest regression test needed in the affected frontend or backend area, then fix the product behavior.
If the scenario exposes only runner fragility, fix the runner instead of weakening assertions.

Required Browser Flow

Log in as a real admin through the supported login surface.
Open /permissions and verify the page heading renders.
Create a new top-level permission through the page modal and wait for the real create API response.
Create a child permission under that top-level node and wait for the real create API response.
Switch to list view and verify the new permissions appear.
Edit the top-level permission through the page modal and wait for the real update API response.
Toggle the permission status through the page action and wait for the real status API response.
Delete the child permission, then the top-level permission, each with real delete API responses.
Verify the created records are gone from the visible page state.

Verification

Targeted red/green loop:
- cd frontend/admin && $env:E2E_SCENARIOS='permissions-management-crud'; npm.cmd run e2e:full:win
If product code changes:
- run affected frontend tests first
- then cd frontend/admin && npm.cmd run test:run
- then cd frontend/admin && npm.cmd run lint
- then cd frontend/admin && npm.cmd run build
Final acceptance:
- go test ./... -count=1
- go vet ./...
- go build ./cmd/server
- cd frontend/admin && npm.cmd run test:run
- cd frontend/admin && npm.cmd run lint
- cd frontend/admin && npm.cmd run build
- cd frontend/admin && npm.cmd run e2e:full:win

2.7 KiB Raw Blame History