管理者による承認機能を設定しようと考えているのですが、皆様どのように設計されていらっしゃいますでしょうか。具体的には、申請者がレコードを新規作成後、管理者が承認し、その記録を残し、その後、管理者以外は更新できないようにしたいと考えています。
現在の構成は以下のようにしています。
・出荷テーブル
・承認者テーブル
私の浅い考えでは、「出荷テーブル」に承認フラグ(Y/N)を用意し、「承認者テーブル」にメールアドレスを登録し、承認者で出荷テーブルを表示したときのみ承認フラグ(Y/N)を表示するようSHOW?でコントロールするという方法です。
もしアドバイスを頂けたら大変幸いです。
ありがとうございます! tsujiさんにレビューいただいて、方向性がそれほど違っていなかったので、嬉しかったです ご指摘の通り、AppSheetは思い描くロジックを柔軟に実現できる懐の深さがありますよね 一方でまだ慣れていない身としては、ちょっと無茶な実装してしまって、あとから後悔しそうなケースに遭遇する可能性をヒシヒシと感じています🤣 ご助言参考にさせていただいて、保守性に関しても学んでいきたいと思っております!
基本的に「お作法」的なものはなく、思え描くロジックを関数をもって実現していくだけで、結果が同じであればアプローチは問われません。但し、プログラミングと同じで関数はシンプルであることが望まれますが。
ROW自体をロックしたいのであれば、ご記載の手法、別途「ロック」というカラムを設けるのも一手ですし、前回私がご紹介したような関数をすべてのカラムのEDITIFに設定するのも一つのアプローチです。MIYAIさんのアプローチですと、レコードロックがTRUEの場合、すべてのレコードへの入力が制限されるような仕組みと思います。その場合、例えば、approvalのステータスがApprovedと変更されたらWorkflowを走らせレコードロックの値をtrueに変更するといった仕組みを取り入れることが必要になると思います。ただし、それだけですと一度承認されたレコードは以降だれも変更・修正できなくなってしまうので、それも回避したいというのが実務で見られるケースです。
アプリの管理者・アドミンを設定し、その人間でれば、承認後もレコードを出来るような仕組み、つまりは関数に基づくロジックも取り入れることが必要なケースが多いと思います。
ユーザーテーブルにadminといったカラムを設け、trueであれば、editifの制限からはずれどんな条件でも編集可、としておくような必要ですね。単にif 関数をnestさせるだけの簡単な処理でこのような複雑な設定も実現できますね。
YSさん、tsujiさん
のっかって質問失礼します
tsujiさん間違ってたらすみません
ご教示いただいた設定の場合、[承認ステータス]カラムの編集権限のコントロールになっている認識です
今回はあえて検討フォーカスから外されていると思うのですが、「承認済みレコードは編集不可とする」も良くある要件になるかと思います
その場合は以下実装にて動作することは確認していますが、筋の良い実装方法でしょうか?
* [レコードロック]のYes/No項目を作成
* 承認時にYesになるActionを設定
* [承認ステータス]の、Valid Ifにて、以下のような入力規則を追加
OR( ANY(select(UserTable[Approve], useremail()=[Email]))=true, NOT([レコードロック]) )
AppSheetのお作法に沿っているのかなぁと気になっているのが、質問背景となります
辻様、いつも迅速かつ分かりやすいご回答をいただき誠にありがとうございます。IF文で表示をコントロールできるのですね。大変勉強になりました!やってみます😀
UserTableには、
Name Email Approve
というカラムがあるとします。Approveのカラムでは承認者から否かをyes/noタイプで管理します。
一方出荷テーブルには[承認ステータス]といった名称で文書のステータスをENUMで管理。例えばDraft, Request Approval, Approvedで文書のステータス管理をするとします。
ユーザーは二分して申請者と承認者。但し、承認者は申請者にもなれるベース。
承認ステータスのEDITIFの条件・関数に
OR(
ANY(select(UserTable[Approve], useremail()=[Email]))=true,
AND(
ANY(select(UserTable[Approve], useremail()=[Email]))=false,
[承認ステータス]=Draft
)
)
と入れることでokと思います。アプリ内で動かしてはいませんが。
ログインユーザーがUserTableでApprove = trueであれば、承認ステータスのvalueに関わらず編集可。つまり値を自由に設定できる。
一方、Approve = False, 承認権限無しの場合。そのRowの承認ステータスがDRAFTの時だけ変更可能。
但し、これだけだと、承認者でない人間が直接approvedに値を変更することが出来てしまいます。
これを回避する手法はいくつかあると思いますがEnumカラムのSuggested Valueの欄に
If(
ANY(select(UserTable[Approve], useremail()=[Email]))=true, {“Draft”, “Request Approval”},
{“Draft”, “Request Approval”, “Approved”}
)
と入れることで、承認権限の有無により動的にdropdown, buttonで表示させるオプションを変更することが可能です。
辻様、いつも貴重なアドバイスをいただきありがとうございます。USEREMAIL()とスライスを使った表示のコントロール方法は素晴らしいですね。実際にできたときには感動しました。
1点だけ、「ENUMをAPPROVEDに変更できるのは、承認者のみ、と関数で指定、」の実現方法がどうしても分からいのですが、どのように関数を指定するイメージでしょうか。
承認機能、プロセスの実装は極めて一般的な要求と思います。いくつかの手法がありますが、一般的には、まずアプリのユーザーを管理するテーブルを作成、アプリに読み込み。そこにはアプリユーザーのメールアドレスに加え、別途カラムを容易し、例えば、その人がAPPROVERか否かのYES/NOのフラッグを準備。
例では出荷テーブルには、ENUMを設置し、DRAFT、REQUEST FOR APPROVAL、APPROVED
といったカテゴリーを準備。ユーザーが新たな行を作成した段階では初期値のDRAFT.同時にこの行にもUSEREMAL()の関数で誰がその行を作成したのか?を認知し、その人間しかEDITできないようにEDITIFでコントロールします。そして、DRAFT段階からREQUESET FOR APPROVALに値が変更されたと同時に、他のユーザーにも見えるようにSLICEで制御。
ログインしているユーザーが承認者か否かは、冒頭のユーザーテーブルにて管理。自動認識させます。
ENUMをAPPROVEDに変更できるのは、承認者のみ、と関数で指定、あた行のデータ自体の編集も承認者のみ、とEDIFIFで制限することで目的を達成できると思います。