ruoyi-vue-pro/docs/education/migration/issues/EDU-018-native-payment-social-admin.md

EDU-018 — Reuse native payment and social-provider administration

• Status: done — bounded native-administration reuse implemented and verified
• Type: tenant administration / module reuse
• Phase: 4 / tenant operations
• Blockers: EDU-017, Pay module, System social-client module, Vben admin foundation

Decision

Legacy tenant_payment_accounts and supported OAuth-provider administration must not become Education-owned shadow tables. Payment applications/channels remain authoritative in Pay; tenant third-party login clients remain authoritative in System. V4300 places their existing Vben pages under the Education menu and grants only their original granular permissions.

The duplicated menu locations use unique route names, so roles may receive Education-scoped navigation without changing the original Pay/System routes. All requests still reach the native controllers and services. No credential is copied into Education and no compatibility facade invents a second status model.

Delivered contract

• Education menu entry for native pay/app/index with Pay App and Pay Channel query/create/update/delete permissions.
• Education menu entry for native system/social/client/index.vue with Social Client query/create/update/delete permissions.
• Fail-closed Flyway menu-shape validation and collision detection.
• Existing Pay/System Vben forms, controllers, tenant interception, and validation are reused. EDU-020/V4320 subsequently activates the Pay runtime and supplies the missing tenant-scoped App/Channel PostgreSQL contract.

Verification

• Real PostgreSQL Flyway test verifies both route components, unique route names, all twelve native permissions, and V4300 history.
• A conflicting pre-existing menu ID causes V4300 to fail rather than silently binding the wrong permission.
• The existing Vben production build already compiles both reused native pages; V4300 adds no frontend source or dependency.

Explicitly open

• EDU-021 now maps bounded tenant_collect WeChat/Alipay accounts into native Pay with a redacted audit. Platform/service-provider modes, XPay/Xunhu replacement, and production bulk export/runbook work remain open.
• system_sms_channel is global and @TenantIgnore; it is not legacy tenant-level auth-provider equivalence.
• Aliyun PNVS has no proven native target provider and remains a separate auth/SMS slice.
• Generic tenant secret storage/rotation remains separate. Native Pay/System credentials stay owned by those modules.
• Activation codes and coupons remain a Mall Promotion/Member entitlement and idempotent-redemption slice.