fix: 收窄详情按钮并校正响应式回归(09-04-reimbursement-state-gap-finance-view)
这个提交包含在:
@@ -20,6 +20,8 @@ and verification contracts. Do not copy broad aesthetic guidance from
|
||||
- PC uses `asideContext` for current progress after `actionPanel`, with `lg:static` on the action card. Payment detail and reimbursement approval share this order; comments remain readable without horizontal overflow. Mobile retains its own safe-area action contract.
|
||||
- Test absent batch, review, export, receipt, paid, failed/cancelled, missing progress and no batch-read permission. Test create/review/export with real isolated roles, then return from batch to reimbursement. Include visibility return and refresh; a payment-only test does not prove the source detail is correct.
|
||||
- Wrong: `approved => create batch`, or `!targetHref => no batch`. Correct: stage-derived next step and one server-authorized destination, including a conservative unknown state.
|
||||
- Reimbursement desktop payment links use content width (`justify-self-start`) and the existing 44px button height, not grid stretching across the aside. The creation label is `创建批次`; it navigates to the existing pending view and never creates a batch itself. Keep mobile touch sizing and the generic action-panel layout unchanged. Verify actual desktop bounds and that navigation sends no batch-creation POST.
|
||||
- When `PaymentBatchesPage` retains its `lg:hidden` mobile action bar, its desktop action card must keep `hidden lg:block` as well as `lg:static`; changing stickiness must not remove responsive visibility. The adjacent progress stays visible. Cover the narrow PC route in addition to the dedicated mobile route, including receipt-upload action switching.
|
||||
|
||||
## Scenario: Actionable Validation And Selectable Payment Channels
|
||||
|
||||
@@ -612,6 +614,7 @@ reference, not a copy of Feishu or Ant Design branding.
|
||||
- Mobile reimbursement approval is offline -> no evidence is loaded from IndexedDB and no approval draft is allowed; an explained disabled state remains visible.
|
||||
- Mobile edit/approval has a bottom action -> fixed bar is visible at the viewport bottom and final evidence remains reachable above it. No bottom action -> no fixed-action page padding.
|
||||
- Current or historical assigned reviewers may read the authorized current evidence; unrelated employees remain forbidden. Material endpoints continue their own permission, governance, audit and short-lived WeCom grant checks.
|
||||
- Supplementary attachment browser tests locate the intended file within `approval-attachments` by its accessible `查看补充附件:<filename>` control, then activate that row's `删除附件`. Do not depend on the retired `.detail-evidence-card` reimbursement layout or restore old product markup for a test. Preserve object/consequence copy, zero DELETE requests on cancellation or fewer than two reason characters, and exactly one target-specific DELETE carrying a valid reason; a mock browser pass does not prove persisted or production deletion.
|
||||
|
||||
### 5. Good/Base/Bad Cases
|
||||
|
||||
|
||||
在新工单中引用
屏蔽一个用户