[第39回] DB担当者が変わっても承認規則はそのまま

規則で申請先を定められるが、DB担当者変更時は規則内の承認者も直す必要があるのだろうか。

Connection Ownerを承認先にし、1件処理後に担当者だけを変更して、同規則の次申請を誰が受けるか試した。

接続担当者を承認先にする

新規則を EP39 - Connection Owner Approvalと名付け、SQL Requestと承認方式 Assign Connection Ownerを選んだ。実行者はDemo Developer、自己承認は無効だ。

実習接続は Owner Handoff Labとし、最初はDemo Approver一人をConnection Ownerに指定した。

Connection Ownerは接続ごとの担当で、組織全体のOwnerロールとは別だ。今回は承認割り当てに使った。

開発者にはRead-Onlyを付け、その権限で可能な27002のSELECTを使った。

最初はDemo Approverが承認する

開発者が同規則・Owner Handoff Lab・注文SELECTでAを提出した。担当変更前と分かる印だ。

作成フォームの承認者は Connection Ownerと表示され、提出後の詳細では実際に Demo Approverが割り当てられた。申請者が人名を選ぶ必要はなかった。

担当者が接続とSQLを見て「接続担当として架空注文参照を確認し承認」とコメントした。

開発者が実行し、Resultsに 1 Rows selected, in 4 msと出て承認・実行が完了した。

規則を維持し担当者だけ変える

A完了後、接続の担当からDemo Approverを外し、 Demo Auditor一人に置き換えて保存した。

接続情報とRead-Only、Assign Connection Ownerと実行者は維持した。変更は担当者だけだ。

新申請は新担当へ割り当てられる

BもAと同じ規則・接続・SQLで作った。

フォームは同じConnection Ownerでも、提出後の詳細は Demo Auditorとなり、接続側の変更が反映された。

Demo AuditorがBを確認し「変更後の接続担当として確認・承認」とコメントした。

開発者がBも実行するとResultsに 1 Rows selected, in 3 msと表示され、変更後も同規則で完了できた。

両申請の処理者も残る

Workflow LogsにA・Bそれぞれ提出・承認・実行の計6件があった。AはDemo Approver、BはDemo Auditorが承認し、両方の申請・実行は開発者だった。

Query Auditでも両SELECTが同接続のSQL Request経由で成功した。最後も規則の方式・実行者・更新時刻は不変だった。

規則の人名を直さず、接続担当の変更だけで新申請が新担当へ届いた。同じ承認方式でDB別担当を管理できる点が便利だった。

QueryPie Community 11.6.7とMySQL 8.0.42で架空ユーザー・注文を使った。

参考： DB Connections · Approval Rules · Workflow Logs