manage-account-permissions

Epic 3：系統與權限管理 (System & Access Control) — 對應頁面：權限管理 設計稿依據：「M+ Admin.html」(2026-08-06)。owl 只定契約意圖；認證/授權實作細節由 cockatiel 決定。 此 change 直接關係到需求清單「設計師會有一組密碼共用（待補）」與「admin 一組共用密碼」， 是解答其他 change 權限層級 Open Questions 的權威來源。

Background

10/3 第一階段上線前，管理員要能管理三種角色的帳號（管理員／設計師／顧客）、能改密碼，而且團隊要有一張清楚的表說明「哪個角色可以做什麼」。現在沒有這張表，其他需求（顧客卡券、卡券方案）各自都在猜要不要分權限；以後統一以這份為準。

目前規格層對權限管理完全空白。

User Stories

P1 US-1

角色帳號管理

查看完整規格 →

P1 US-2

管理員異動共用密碼

查看完整規格 →

US-3

檢視角色權限對照 [P2] — 🚫 本期不做

查看完整規格 →

Edge Cases

• 只剩一個管理員：不能讓最後一位管理員被停用或降級，否則沒人能管權限（這期沒有管理員分級，風險要在規劃階段評估）
• 把自己鎖在外面（2026-08-22 新增）：管理員改了管理員這組密碼，自己也會被登出；如果新密碼打錯或沒記下來，全部管理員都進不來。規劃階段要想防護（例如二次確認、當場把新密碼顯示出來、或留一條救援路）
• 「太短」已定為不到 6 碼；弱／中等／強怎麼分還沒定（見 Open Questions）
• 設計師登入用的共用密碼，跟本頁改的是同一組（2026-08-22 已確認，見 US-2）
• 顧客為個別密碼（2026-08-23 確認），不在本頁的共用密碼異動範圍內。管理員若要協助顧客重設密碼，走的是另一條路徑，見 Open Questions
• 新增帳號要填哪些欄位、帳號編號怎麼產生，這裡沒定，留到規劃階段

Functional Requirements

• FR-001: 權限管理頁有三張可切換的角色卡（管理員／設計師／顧客）和一份帳號列表
• FR-002: 帳號搜尋支援姓名、英文名、Email、手機、帳號 ID
• FR-003: 帳號列表欄位：頭像、姓名／英文名、角色標籤、聯絡方式、職稱／備註、最後登入時間、是否啟用
• FR-004: 顧客帳號在這個後台不能編輯
• FR-005: 改密碼是以整組為單位（設計師組、管理員組）；管理員可以改管理員自己這組，管理員之間沒有分級
• FR-005a（2026-08-24 依設計稿補）: 每位設計師有一組 UUID，共用密碼登入後以 UUID 辨識實際操作者。開卡紀錄須記錄該 UUID，才能追溯是哪位設計師開的卡
• FR-006: 改密碼的視窗要有：這是哪一組（角色、影響幾個帳號、上次改的時間）、即時強度檢查、隨機產生密碼、新密碼與確認密碼兩欄
• FR-007: 「用簡訊／Email 通知受影響的人」預設勾起來（通知那一組的所有人）。原設計稿的「要求用戶下次登入時自行變更密碼」選項在共用密碼制下無意義，暫定移除（見 Open Questions）
• FR-007a: 密碼最低要求：至少 6 碼、要有英文和數字、英文要有大寫也有小寫；不符合就不能送出
• FR-008: 每次改密碼都要留下紀錄（誰改的、從哪個網路位置、時間、改了哪一組）
• FR-009: 提供權限對照表視窗，依帳號／營運／管理／系統四區列出三種角色的 ✓／—

Success Criteria

• SC-001: 切換角色卡和搜尋都能正確篩出帳號
• SC-002: 改完密碼後，那一組的所有帳號 100% 只能用新密碼登入，舊的馬上失效
• SC-003: 每次改密碼都留下含誰改的／網路位置／時間的紀錄，完整率 100%
• SC-004: 權限對照表涵蓋這次上線所有跨角色的功能（開卡／核銷／撤銷刪除／改密碼／看紀錄），一個都不漏

📌 2026-08-24 範圍決議（Jacky）：本期只做設計稿畫的兩區。 ① 管理員帳號（單一）② 設計師管理（共用密碼＋UUID 清單） 規格中的角色 KPI 卡、搜尋框、顧客帳號管理、權限對照表視窗（US-3）本期不做， 保留於下方供日後參考，各處已標記。落差全貌見 design-spec-gap-audit（B-1）。

Related Modules

• （owl 為產品層 spec hub，無程式模組）
• 後端：目前只能「看」員工名單，不能新增、修改或刪除帳號，也不能改密碼，更沒有留下異動紀錄，這些都要新做
• 後端：現在的登入機制與本頁要做的共用密碼異動必須對齊（目前實際狀況見 implementation-notes.md）
• 後端：設計師的 UUID 識別機制需要新做——共用密碼登入後，開卡時要能指出是哪位設計師
• 前端：管理後台目前沒有這個頁面，需新做

Open Questions

2026-08-22 由 Jacky 逐題答覆（Ci 轉述）。決議彙整見 docs/grooming/2026-08-22-admin-console-open-questions-resolved.md。

• 管理員之間是否可互相異動密碼 — 2026-08-22 決議：可以。原「管理員之間不可互異」限制取消。權限層級仍僅分管理員／設計師／顧客三層，無管理員內部分層；此結論為 manage-customer-vouchers、manage-voucher-products 的權威來源
• 「設計師共用密碼登入」與「異動設計師密碼」的關係 — 2026-08-22 決議：異動的是共用密碼本身，改一次全體設計師須用新密碼登入。視窗已改成顯示「哪一組」而非個人（見 US-2）
• admin 帳號是否也是共用密碼 — 2026-08-22 決議：是，且管理員可更改。原「共用密碼 vs 不可互異」的矛盾已消解——因為不可互異的限制被取消
• NEEDS CLARIFICATION: 密碼最低要求已定義（至少 6 碼、含英文字母與數字、含大小寫），但強度條四級距中「弱／中等／強」的區分規則仍未定義——目前只有「太短（未達 6 碼）」與「合格下限」兩個明確點
• 顧客密碼是否同為共用 — 2026-08-23 Jacky：顧客密碼不會是共用的。三種角色的密碼制度確立：設計師共用一組、管理員一組、顧客為個別密碼。設計稿也證實顧客不在本頁管理範圍內
• NEEDS CLARIFICATION（2026-08-24 新增）: 設計師 UUID 的細部定義——UUID 從哪裡產生？開卡時設計師如何選擇自己的身分（下拉選單？輸入？）？UUID 是否對顧客可見？
• NEEDS CLARIFICATION（2026-08-23 新增）: 管理員能否重設「某一位顧客」的個別密碼？若能，屬另一個 Story；若不能，顧客忘記密碼的救援流程是什麼？
• NEEDS CLARIFICATION（2026-08-23 答覆與問題不對應，需重問）: 「要求用戶下次登入時自行變更密碼」這個選項，在共用密碼制下已無意義（設計師與管理員沒有個別密碼可改）。2026-08-23 的答覆是「顧客密碼不會是共用的」，回答的是上一題。
  • 暫定處置：本頁範圍只處理共用密碼，該選項先移除
  • 建議回問：「密碼視窗上那個『要求用戶下次登入時自行變更密碼』，因為改成共用密碼了，設計師和管理員沒有自己的密碼可改，直接拿掉可以嗎？」

Constitution Check

• Reviewed against prospec/CONSTITUTION.md
• P1（owl 是產品層）：PASS — 描述權限行為與對照關係，未涉及認證技術實作
• P2（契約意圖在 owl、實體在 cockatiel）：PASS — 未指定認證機制實作細節
• P3/P4（兩軌分離、協調點）：PASS — 無新增手動同步步驟

UI Scope

Scope: full

（設計稿已存在：M+ Admin 權限管理頁。）