one-pipe-system/openspec/changes/update-enterprise-asset-authorization-entry/design.md

Context

Enterprise asset authorization currently has two hidden pages launched from enterprise customer rows. The requested workflow moves those operations to the asset lists so users can filter assets by enterprise authorization state and act on the same list they export from.

Goals

• Add enterprise authorization filters to IoT card management and device management.
• Add direct card/device enterprise authorization and recall actions beside existing export actions.
• Protect each new action with an independent button permission code.
• Remove enterprise customer row authorization shortcuts and the replaced “企业卡管理” / “企业设备列表” hidden pages.

Non-Goals

• Do not change backend endpoint paths.
• Do not add new route pages for this workflow.
• Do not preserve compatibility routes for the old “企业卡管理” or “企业设备列表” pages unless a product requirement is added later.

Decisions

• New permission codes:
  • iot_card:authorize_enterprise for “授权卡给企业”.
  • iot_card:recall_enterprise_authorization for “回收卡授权”.
  • devices:authorize_enterprise for “授权设备给企业”.
  • devices:recall_enterprise_authorization for “撤销设备授权”.
• Authorization and recall dialogs will require a target/source enterprise ID, except recall may prefill or lock it when authorized_enterprise_id is present in current filters or a single selected-row enterprise ID can be safely inferred from list response data.
• List-mode operations use selected rows. Card operations submit iccids; device operations submit device_nos derived from available list response identifiers such as virtual_no.
• Filter-mode operations submit only non-empty filter fields supported by docs/授权、回收.md.
• The shop_id filter in “授权卡给企业” and “授权设备给企业” dialogs uses the same lazy ElCascader tree pattern as the add-shop dialog’s “上级店铺” field: ShopService.getShopsCascade({ parent_id }), checkStrictly: true, and submit the last selected path node as shop_id.
• Old hidden pages are deleted rather than kept as redirects because the list-page authorization workflow replaces “企业卡管理” and “企业设备列表”.

Risks

• The list response field names for enterprise authorization metadata may vary. Implementation should read current API response types and use returned fields when available; if a required source enterprise cannot be inferred, require explicit enterprise selection in the recall dialog.
• Existing add-enterprise-device-authorization OpenSpec change overlaps conceptually but proposes a separate enterprise-device page. This change supersedes that approach for the current product direction.