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错误
This commit is contained in:
@@ -0,0 +1,60 @@
|
||||
# Permissions Browser CRUD Implementation Plan
|
||||
|
||||
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
|
||||
|
||||
**Goal:** Add a real browser CRUD scenario for the admin permissions page and keep the supported E2E gate green.
|
||||
|
||||
**Architecture:** Extend the existing Playwright CDP runner with one new scenario and only touch product code if the new scenario exposes a real defect. Keep assertions aligned with the page's current tree/list modal workflow and wait on real API responses for every mutation.
|
||||
|
||||
**Tech Stack:** Playwright CDP runner, React admin frontend, Go backend APIs, Vitest for regressions when product fixes are needed.
|
||||
|
||||
---
|
||||
|
||||
### Task 1: Add the red browser scenario
|
||||
|
||||
**Files:**
|
||||
- Modify: `frontend/admin/scripts/run-playwright-cdp-e2e.mjs`
|
||||
|
||||
- [ ] Add a new scenario entry named `permissions-management-crud` to the supported scenario list.
|
||||
- [ ] Implement the scenario with real page navigation and mutation-response waits for create, update, status toggle, and delete.
|
||||
- [ ] Run `cd frontend/admin && $env:E2E_SCENARIOS='permissions-management-crud'; npm.cmd run e2e:full:win`.
|
||||
- [ ] Confirm the first run fails for a real reason before changing product code.
|
||||
|
||||
### Task 2: Fix the exposed product issue if needed
|
||||
|
||||
**Files:**
|
||||
- Modify only the minimal affected product files revealed by Task 1
|
||||
- Test: affected frontend/backend regression tests only if product behavior changes
|
||||
|
||||
- [ ] Add the smallest failing regression test for the exposed product bug.
|
||||
- [ ] Run that regression test and confirm it fails for the expected reason.
|
||||
- [ ] Implement the minimal product fix.
|
||||
- [ ] Re-run the regression test until it passes.
|
||||
|
||||
### Task 3: Verify the new scenario end to end
|
||||
|
||||
**Files:**
|
||||
- Modify: `frontend/admin/scripts/run-playwright-cdp-e2e.mjs`
|
||||
- Modify: docs only if the supported browser conclusion changes
|
||||
|
||||
- [ ] Re-run `cd frontend/admin && $env:E2E_SCENARIOS='permissions-management-crud'; npm.cmd run e2e:full:win`.
|
||||
- [ ] Confirm the targeted scenario passes without weakening assertions.
|
||||
- [ ] Run `cd frontend/admin && npm.cmd run e2e:full:win`.
|
||||
- [ ] Confirm the full supported browser gate stays green with the new scenario included.
|
||||
|
||||
### Task 4: Re-run the full matrix and sync docs
|
||||
|
||||
**Files:**
|
||||
- Modify: `docs/status/REAL_PROJECT_STATUS.md`
|
||||
- Modify: `docs/team/PRODUCTION_CHECKLIST.md`
|
||||
- Modify: `docs/team/TECHNICAL_GUIDE.md`
|
||||
- Modify: `docs/team/PROJECT_EXPERIENCE_SUMMARY.md`
|
||||
- Modify: `docs/team/QUALITY_STANDARD.md`
|
||||
|
||||
- [ ] Run `go test ./... -count=1`.
|
||||
- [ ] Run `go vet ./...`.
|
||||
- [ ] Run `go build ./cmd/server`.
|
||||
- [ ] Run `cd frontend/admin && npm.cmd run test:run`.
|
||||
- [ ] Run `cd frontend/admin && npm.cmd run lint`.
|
||||
- [ ] Run `cd frontend/admin && npm.cmd run build`.
|
||||
- [ ] Update docs only with the results actually observed on this branch state.
|
||||
@@ -0,0 +1,54 @@
|
||||
# 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
|
||||
|
||||
1. Log in as a real admin through the supported login surface.
|
||||
2. Open `/permissions` and verify the page heading renders.
|
||||
3. Create a new top-level permission through the page modal and wait for the real create API response.
|
||||
4. Create a child permission under that top-level node and wait for the real create API response.
|
||||
5. Switch to list view and verify the new permissions appear.
|
||||
6. Edit the top-level permission through the page modal and wait for the real update API response.
|
||||
7. Toggle the permission status through the page action and wait for the real status API response.
|
||||
8. Delete the child permission, then the top-level permission, each with real delete API responses.
|
||||
9. 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`
|
||||
Reference in New Issue
Block a user