事象
dev 動作確認(S-08 ユーザー管理)で、メンバー削除の確認ダイアログが ブラウザ標準の window.confirm() で表示される。アプリの Bootstrap ベース UI と見た目が不統一で、SaaS 製品としての体験上気になる、との指摘(2026-06-28)。
該当
web/js/tenant-users.js の削除ボタン: if (!window.confirm(...))。
- 他にも
window.confirm を使う箇所がある可能性(要 grep: web/js/*.js)。
論点
window.confirm は CSP 安全・実装が簡単(ADR-0022 のインラインハンドラ禁止とも無衝突)だが、スタイル不可・OS 依存の見た目・モーダル多言語/文言制御不可。
- 改善案: アプリ共通の 確認モーダル(Bootstrap modal)コンポーネントを用意し、破壊的操作(削除・状態変更等)はそれに統一。
app-* カスタム要素群(web/js/components/)と同じ流儀で app-confirm-dialog 等を作る案。
優先度
UX 改善(機能バグではない)。MVP ブロッカーではないが、破壊的操作の確認 UX は統一したい。native 書き込みバグ(#810)とは無関係。
事象
dev 動作確認(S-08 ユーザー管理)で、メンバー削除の確認ダイアログが ブラウザ標準の
window.confirm()で表示される。アプリの Bootstrap ベース UI と見た目が不統一で、SaaS 製品としての体験上気になる、との指摘(2026-06-28)。該当
web/js/tenant-users.jsの削除ボタン:if (!window.confirm(...))。window.confirmを使う箇所がある可能性(要 grep:web/js/*.js)。論点
window.confirmは CSP 安全・実装が簡単(ADR-0022 のインラインハンドラ禁止とも無衝突)だが、スタイル不可・OS 依存の見た目・モーダル多言語/文言制御不可。app-*カスタム要素群(web/js/components/)と同じ流儀でapp-confirm-dialog等を作る案。優先度
UX 改善(機能バグではない)。MVP ブロッカーではないが、破壊的操作の確認 UX は統一したい。native 書き込みバグ(#810)とは無関係。