Pleasanter でレコードの編集を制限する

2022 個人アドベントカレンダー の記事です。

試したこと

• 一定の条件で、自動的に編集をさせないような仕組みについて考えてみた。
  • ワークフローにおける承認や、あるいは投票行為の、回答期限みたいなことができないか、を想定。

考えたこと

• プリザンターにはロックという仕組みがある
  • システム予約の項目
  • ロックをかけたユーザまたは特権ユーザしか解除できない。サイトの管理権限やテナント管理権限でも解除できない。
  • SaaS だと特権ユーザが存在しないので、そのユーザ自身にしか解除できない。グループウェア的なサービスではレアな機能な気がした。
• 一方で「ロックする」というアクションがユーザの行動依存になる(時限など条件でのロックはできない)
  • 典型的には、自分で自分のレコードにロックをかけるアクションが想定されてそう。

ということで、プロセスと状況による制御で考えてみました。

状況による制御

ここでは、レコードの作成や更新に期限を設けて、アンケートの回答期限のようなことができる仕組みを考えました。

具体的には、例えば次のようにして、日付 A を条件項目にして、時限で編集を制限することができそうです。

• 項目の設定
  • 日付 A に既定値として 0 を指定
  • 書式は期限の指定方法(日付単位なのか、時間や秒の精度なのか)で決める
  • 読み取り
• フィルタの設定
  • 日付 A のフィルタの指定として「範囲」を選択

この状態で、

• 状況の制御の条件タブで
  • 日付 A の終了側に期限となる日時を指定
• 全般タブで
  • 読み取り専用にチェック

とすると、新規作成ができなくなります。

こうすれば、「投票」や「アンケートの回答」のように 1 回的なアクション(=作成)に時限を設けることができます。

また、プロセスで更新をした日から、一定の加算をした期限を日付 A に設定すれば、作業期限を設けることもできそう。

一定回数の変更

ここでは、レコードの更新に回数の期限を設けて、テストにおける回答し直しを一定回許容する対応を考えました。

ユースケースとして、選択肢型のテストにおいて、再選択は許したいが、総当たりは困るといった場合を想定します。
(実際にこういうことをするには、出題や合否の判定は別途スクリプトなどで補完する必要があります)

具体的には、数値 A 項目を使って 5 回の"更新"を許すようにしてみます。

• 項目の設定
  • 数値 A の初期値に 16 を指定
  • 読み取り専用で、最大値を 16 最小値 9 に設定
• フィルタの設定
  • 数値 A のフィルタの指定として「範囲」を選択
• 状況による制御の設定
  • 数値 A が 9 - 9 の条件を作成し、読み取り専用にチェック
• プロセスの設定
  • 現在の状況および変更後の状況を * に指定
  • 実行種別は 作成または更新 を選択
  • 条件として、数値 A が 10 - 10 を指定
  • データの変更で、値の入力として
    • ロックに 1 を設定
    • 数値 A に 11 を設定

このようにすると、作成直後の時点で数値が 15 となり、更新を押すごとにカウンターが減算されます(実用的に"残り編集回数"を出すには、数値 A から 10 を引いた値を別の数値項目に持つのもよさそう)。

そして 5 回目の更新でロックがかかります。

さらに、自分でロックを外したとしてもその瞬間、数値 A は 9 となり読み取り専用となるため、さらに編集はできなくなります。

実装して分かったこと

状況による制御は、相対的な日付に対応しない

"今日" のような相対的な日付に対応していません。ただ、時限を考える上では、今日や今月で設定するとむしろ期限がずれてしまうので、今回問題にはなりませんでした。
また、今日が期限である、はレコードの棚卸しでは必須ですが、それによって個々のレコードの編集画面の状態を変えたいかというと微妙なので、もしかしたら練りに練った仕様なのかもしれません。

状況による制御で 0 付近の動作がおかしい

^ の例の回数制限の例で、数値を 10 付近で調整したのは 0 で設定すると、状況による制御が正しく範囲を識別しないように見えたためです。
同等に思える指定をしても 10 で完了となるようにするとうまくいくものが 0 を基準として指定すると上手く動作しませんでした。

補足

既にプログラム的には修正済みですが、現時点で demo.pleasanter.org は 1.3.25.2 なので ↓ の影響を受けます。

12/9 リリース情報(ver.1.3.26.1)
・項目の制御を含まない状況による制御が設定されたテーブルで自動ポストバック時に null 参照違反が発生する問題を解消。

このため、回数制限のような、読取専用だけの設定を持つ定義を置くと「アプリケーションでエラーが発生しました」となります。
回避策として、もともとユーザが変更できない ID や無効にしている項目に読み取り専用を付ける、方法が考えられます。

ロックの特異な仕様

次の点で個人的にはロックの動作に違和感を覚えました。

読取専用でもロック外せる、がロックを付けることはできない。

読み取り専用にしていても、ロックを外す操作は可能です。

一方、ロックを付ける操作はできません(ロックを付ける、は更新行為にあたるため)。

ここは仕様としてどちらかに寄せて欲しかったところです。
個人的には、ロックに読み取り専用が影響すれば、ユーザ側とサイト管理者側で、相互に相手の独断の変更に制御をかけあえるので、良いのではないかなと思います。

ロックしていても削除できる

仕様としてはあり得る選択だとは思いますが、ロックされていても削除が可能であることにご留意ください。

数値項目の最小値

プロセスや計算式を使うと、最小値以下の値を設定することが可能です。
予期しない値になったときに、制御が外れるのを防ぐため、状況による制御は、開始もしくは終了の片方だけを指定したほうがいいかもしれません。

計算式の動作

• 画面を表示したときに、計算式が実行されます。
  • このため ^ の例では、画面に違和感を生じないよう、数値 A の初期値を 16 としました。
• プロセスの、データ変更の 1 つ 1 つ(1 ID ごと)に、計算式が実行されます。
  • このため ^ の例では、プロセスで数値 A を一旦 11 に再設定しています。

このため、今回のように自身に再代入する操作をするとき、初期値や条件値には十分に注意が必要です。

さらに、自動ポストバックをすると、そのタイミングで計算式が実行されます。
ただし、編集を経ない場合、その後の更新で再度計算がし直されることはありません。
これは、新規の場合も同様で、新規画面が描画された時点で、一旦計算が実行された状態となりますが、「新規作成」を押しても、画面に見えている値が変更されていない場合、再度計算が実行されることはありません。
(逆に、ポストバックや新規作成で計算された値を編集すると、その値に対して再度計算が働きます)

動作として、画面上の値が編集された判定でないとき、データベース値(初期値)に対して計算が働く結果、画面に見えている値に再計算が働かないものと考えられます(この振舞いはもしテストがあったら問われそう)。

おわりに

もともと考えていたのは、地デジのボタンを使ったクイズやジャンケンだったのですが、どうしても正否判定がスクリプトにならざるを得ず、自分の中でユースケースが消化し切れませんでした。

ただ、投票・回答期限のあるアンケートの期限の部分は、まずまず利用できそうな印象です。

設定をあーでもないこーでもないと触っていると、面白い振舞が見付けられたので、趣味のレベルでは満足でした。