Zenn
🍊

Pleasanter でテーブル内で項目の移行をする

2022/12/12に公開
#
pleasanter
tech

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

ゴール

  • 1 テーブル内でデータ型を変更することについてプロセスの一括処理が良いのでほないか、という提案
  • 一括更新と一括プロセスのの使い分け

テーブル内でデータ移行

  • 運用をはじめたけど、データを移動させたくなった
    • 空けていた項目や使わない項目があるので、詰めたくなったなど
  • データ型を変更したくなった
    • 説明をノーマル(1 行)にしていたが、入力がある程度絞られているので、分類にするなど

など、同一テーブル内でデータ項目を移行したいことは、ない話ではない。

プロセスの一括処理

プロセスには、一括処理を許可する設定がある。が、次の点で非常に使いにくい。

  • 一覧で表示されるとき、レコードの状況によらず全ての「一括処理を許可」されたプロセスが表示される
  • 一覧用のプロセス名がない

具体的な問題

一覧では、「一括処理を許可」したプロセスが全てプルダウンに表示される。
都度レコードのに条件を当てて検証すると無駄に負荷が高まるとも予想されるので、分からないでもない仕様ではある。
が、およそ選択できないものが見えてユーザを迷わせるのは UI 的には微妙なうえ、以下の問題が影響する。

FAQの例にあるとおり、ワークフロー的に状況を遷移させてデータを様々なユーザにハンドリングさせる場合、取るべきアクションに応じてボタン名を決定すると、複数のプロセスの表示名が「承認」や「差戻」になる。
ワークフローシステムを作ったことがあれば当然理解されると思うが、例えば役職ごとに「課長承認」「部長承認」という表示を置くことはない。そのユーザにとって、それが職位に基づく承認であることは自明だし、課長、課長代理、主任が承認できる、といった場合にそこに適切な表示名を付けるのは困難な場合も考えられる(1 次承認という名前ほど無意味なものはない)。

このような名前が衝突している場合に、一覧のメニューに全てのボタンが出ると、"承認" が複数個並ぶ可能性がある。そうすると、どの承認がどのレコードに適用するものなのかユーザは選べない。
そのため、"課長承認"のようなシステム都合の名前を付けざるを得ず、これが単一レコードの編集画面にも影響してくる。

もちろん、プロセスにアクセス制御を付けて。操作できるプロセスは限定すべきではあるが、先の FAQ のようにグループ(職位)でのアクセス制御と組織(経理部か否か)でのアクセス制御が併存する場合、経理部課長にとって、課長の"承認"ボタンと経理部の"承認"ボタンが 2 種表示されるといった自体は回避しようがない。
(編集画面では、レコード側の状況がプロセスを取捨するので、状況によってグループと部門で制御される 2 種の承認プロセスが同時に出ることは考えにくいし、そうなって良いワークフローなら両方に承認という名前を付けることはないだろうし、一覧に両方が出てよい)[1]

使いどころ

このため、プロセスの一括処理は

  • ステップの少ないワークフロー
  • ワークフロー以外でデータ変更する場合

で利用するのが妥当

プロセスでデータ移行

テーブルの管理のプロセスタブで

  • 現在の状況 * 変更後の助教 *
  • データ変更タブで、値のコピー もしくは 表示名のコピー でデータを指定する

だけ。

migratebyprocgen.png
migratebyprocmod.png

ちなみに、表示名か値かは、コード表現されるデータのときには差異が出てくるので注意[2]

あとは、一括処理で選択するだけ。

元のデータをクリアしたい場合、↑ に追加で元データ項目に「値の入力」を追加して、値の欄を空白のままとすればよい[3]

注意

分類型を単一の選択から複数選択型にすることはできない。
同じ分類型だからといって、同じ項目をエディタの設定で変更してもうまくいきません。

これは、複数選択が内部的に、文字列型の配列の JSON 文字列としてデータを保持している仕様に起因しますし、そもそもプロセスでは複数選択がうまく扱えない(例えば、承認したユーザを追加する、といったことができない)ので、どうしてもの場合は、エクスポートしてインポートのような手作業しかなさそうです。

一括更新との使いわけ

プロセスでの一括処理は、データ処理としてできることとしては「一括更新」機能の上位互換になる。
というのは一括更新は、全てのレコードに同じ値しか設定できないが、プロセスは同じ固定値にすることも、レコードの内容をコピーしたり、日付を計算してずらしたりすることもできる[4]。

なので、一覧上で、その場で何パターンかの固定値を複数の群に適用したい、といった場合でなければ、一旦プロセスを作ったほうが便利。

おわりに

プロセスは FAQ 的にも機能分担的にもワークフローを実現する位置付けのように見えるが、複雑なワークフローの実現よりはむしろその名のとおり編集に連動したアクションをかける、まさにデータプロセッサ的な使いかたをするのが良さそう

脚注

  1. この点、おそらく仕様バグと見てよくて、プロセスとビューが互いに関連していたほうが良かったと考えられる。通知などは条件をビューに依存する一方、プロセスは条件を自身が持つ結果、設定がビューから独立しており、そのためにボタンの表示制御を細かく制御できない問題が生じてしまっている。 ↩︎

  2. 例えばユーザの場合、"値のコピー"だとコード値が、"表示名のコピー"だと名前がそれぞれコピーされる。 ↩︎

  3. この場合、データベース的には null ではなく空の文字列が設定されるので注意が必要。日付の場合 NULL にできる余地があるし、数値も DB に System.String.Empty は入らないので NULL になるかもしれない。最も気をつけないといけないのは、複数選択の分類型は、値が設定されたことのない場合 NULL が、設定されて、クリアされた場合に "" もしくは "[]" が入る可能性があること。今回のように '' にクリアしたとき NOT NULL でかつ JSON.parse に失敗する状態となるので、サーバスクリプトで処理するとき NULL でないとき JSON.parse すると不正な文字列でエラーになるので十分に注意されたい。 ↩︎

  4. 複数項目の一括更新、もプロセスで実行可能 ↩︎

GitHubで編集を提案

Discussion