Partner User Permission Scope Implementation Plan

For agentic workers: REQUIRED SUB-SKILL: Use superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (- [ ]) syntax for tracking.

Goal: Keep partner user-list data limited to users who charged at the partner's sites while allowing all user-management actions strictly according to configured permission keys.

Architecture: Retain PartnerAppUserAccessService.getVisibleUserIdsForCurrentPartner() for list filtering and assertUserVisible() for object-level authorization. Remove the blanket partner read-only rule, apply visibility checks to every mutation targeting existing users, and remove frontend isPartner overrides so Access is the sole button-control mechanism.

Tech Stack: Java 8, Spring Boot, MyBatis-Plus, React, Umi Access, JUnit 5, Mockito

Global Constraints

• Partner accounts only see users who charged at their authorized sites.
• Platform accounts retain unrestricted user-list scope.
• View and mutation buttons follow their existing permission keys.
• Partner mutations may only target users inside the partner-visible scope.
• Do not weaken user-detail visibility checks.
• Do not modify unrelated workspace changes.

Task 1: Object-level partner authorization

Files:
- Modify: ruoyi-service/ruoyi-account/src/main/java/com/ruoyi/account/service/PartnerAppUserAccessService.java
- Modify: ruoyi-service/ruoyi-account/src/main/java/com/ruoyi/account/controller/TAppUserController.java
- Test: ruoyi-service/ruoyi-account/src/test/java/com/ruoyi/account/service/PartnerAppUserAccessServiceTest.java

Interfaces:
- Consumes: getVisibleUserIdsForCurrentPartner().
- Produces: assertUsersVisible(Collection<Long> userIds) for safe bulk mutations.

• [x] Step 1: Replace the read-only test with tests that allow authorized targets and reject targets outside partner scope.
• [x] Step 2: Run the focused test and verify it fails before implementation.
• [x] Step 3: Implement bulk visibility validation and remove assertWritable().
• [x] Step 4: Apply visibility validation to edit, freeze, unit change, delete, and gift-VIP mutations.
• [x] Step 5: Run focused tests and compile the account module.

Task 2: Frontend permission-only controls

Files:
- Modify: chargingPile_management/src/pages/person/list/index.jsx

Interfaces:
- Consumes: existing Umi access keys such as /appUser/select, /appUser/update, /appUser/freeze, /appUser/del, /appUser/giftVip, and /appUser/updateCompany.
- Produces: buttons and row selection controlled only by configured permissions.

• [x] Step 1: Remove isPartner overrides around row actions, row selection, and toolbar rendering.
• [x] Step 2: Keep every action wrapped by its existing Access permission check.
• [x] Step 3: Run the frontend production build.
• [x] Step 4: Review diffs to confirm the partner data filter and backend delete protections remain intact.