Zenn
🍊

Pleasanter 公式 FAQ のアップデート

2022/12/16に公開
#
pleasanter
tech

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

やること

  • 以前の記事に引き続き、公式 FAQ を最新の機能でやるとどうなるか考える

FAQ：サンプルコード：ある項目の値を特定の値に変更したときに別の項目の値を変更する

  • やっていること

クライアントで動作するスクリプトで、状況や分類型項目によって、数値項目やチェック項目を連動して変更させている

  • 現時点での対応

プロセス一択

確かに、プロセスだと画面操作に連動した動的な表示はできないので、プルダウンをかえると数値がかわる、みたいなことはできないけど、ほんとにそこまでしたいのかっていうのと、API とかインポートに対応できないのにやりたいのかっていうところ、疑問

どうしても動的にしたいなら URL にあるとおり、ルックアップと自動ポストバックを併用すればできるけど、別テーブルをメンテナンスしてまでやりたいかは考えたほうがよさそう。

  • プロセスでやるとしたら

実行種別を「作成または更新」にして、データ変更で対象項目に値の入力。ちなみにチェックは 1 のような truely な値を入れとけばチェックがつく。

あと、そもそも状況を変えるアクションは、状況項目を触らせるのではなく、ボタンを押させたほうが選択ミスがないし、通知とかもやりやすい。

FAQ：サンプルコード：ステータスが完了になったら自レコードを削除させたい

  • やっていること

クライアントで動作するスクリプトで、状況が完了だったら削除

  • 現時点での対応

これ自体やるなら、サーバスクリプトの更新後および作成後で api_model.Delete() かけて context.Redirect だと思う。でないと API や CSV インポートに対応できない。

ただ、精査も分析もせずに消すっていうのは実用上は考えにくいように思う。実際はプロセスで状況によってロックするか、状況による制御で読取専用、で十分ではないかなと。
その後でどうしても消したいときは、フィルタして一括削除もできる[1]。

FAQ：サンプルコード：フォームにボタンを追加したい

  • やっていること

編集画面で、分類 A の付近にボタンを追加

  • 現時点での対応

特定の場所にボタンを出したい、のでない限り、プロセスで対応したい。

アクション種別を「無し」にして、OnClick にスクリプトに定義した JavaScript の関数を指定すれば、クライアントに閉じた処理もできるし、保存にすればサーバスクリプトのトリガーにもなれる。

FAQ：サンプルコード：ユーザー入力操作によって別の項目を入力禁止にしたい

  • やっていること

分類 A で特定の値を入力したら、分類 B を読取専用にする。

  • 現時点での対応

状況による制御で。

設定としては、状況による制御のなかの条件タブで分類 A に反応させる値を指定して、全般タブで分類 B を読取専用に指定。

エディタタブの詳細設定で、分類 A の自動ポストバックにチェックを入れるだけ。

FAQ：サンプルコード：ログインユーザごとに規定のビューを変更する

  • やっていること

サーバスクリプトで、デフォルトのビューをユーザごとに指定

  • 現時点での対応

これそのものはサーバスクリプトでの対応となるが、次のような状況であればワークアラウンドが考えられる。

想定する状況として、特定のユーザ群に 1 パターンの表示形式だけを認める、場合を想定。
(つまり、ビューを一覧の制約として使う。例えば、一般社員に限定的な項目のみを表示するなど)

設定として

  1. 制御を受けるユーザ群のそれぞれに対して、具体的なユーザ一人一人には常に 1 つだけのビューが利用可能となるよう、ビューを作成し、各ビューのアクセス制御を割り当てする
  2. テーブルの管理の一覧で、「ビューのリセットを許可」のチェックを外す

こうすると、デフォルトビューが利用できず、かつビューのリセットが許可されないため、自動的に対象のビューに絞られた状態になる。

FAQ：サンプルコード：項目の値の一部を切り取り、同レコードの別項目に転記する

  • やっていること

クライアントスクリプトで、分類 A の最初の 1 文字を説明項目に転記

  • 現時点での対応

要件の見直し。

JavaScript で 1 文字を切り取ると、文字によっては(代表的には emoji )正しく切り取れないので、やらない。
先頭の 1 文字を取り出して有効になる具体的なユースケースが分からない。

検索するなら前方一致をかければいいし、分類が選択肢になっているならコードと文字のペアにして、プロセスで(表示名ではなく)値のコピーをすればいい。

何らかの理由で、容易に正規化できないデータの加工がどうしても必要なら(例えば数字の全角化や文字列の両端のスペースのトリム)サーバスクリプトでやるのが良さそう。

最後に

ざざっと棚卸しで目につくところは全て検討してみた。
Qiita のユーザ記事とかも棚卸したほうがいいんだろうな、と思ったりもしたが、この辺は「あくまでユーザの意見なんで」で何とかなるんだけれども、公式の FAQ として出されてしまうと"ベスプラ"感があるので、機能の説明にあたるものを FAQ で出すのはやめてほしいなと思ったり。

脚注

  1. 一括削除は 1 件ずつの削除の繰り返しなので、あまりにたくさん消すと遅いというか実行時間が長すぎて消し切れない可能性があるので、データイベントに応じて消すというのはロジックとしては理解できる。が、業務データを消す、という発想は個人的にはないなと思う。 ↩︎

GitHubで編集を提案

Discussion