1 回答
- 321
Jira Service Deskの標準機能では項目のEnable/Disable制御はできません。
ScriptRunnerなどのアドオンを使うと項目のEnable/Disableを制御できます。
手順は以下の通り。1 .Behavioursのマッピングを設定
参考：https://scriptrunner.adaptavist.com/latest/jira/behaviours-overview.html?utm_source=product-help
2.スクリプトを設定
// mailフィールドをReadOnlyに設定
getFieldByName("mail").setReadOnly(true);
【結果】検証環境：JSD 3.8.2 / ScriptRunner for Jira 5.3.16 / Chrome 66.0
ReadOnlyに設定した項目が非活性表示になります。
- Kengo Ohsaki
動くんですね！よかった。
- Kaori Komori
正常に動作するように見えたのですが、
ScriptRunnerのバグにより、ServiceDeskプロジェクトのプロジェクトロールでCustomerに設定されたユーザでログインした場合、スクリプトがロードされないことがわかりました。
※Jiraのライセンスに紐づくユーザでポータルにログインするとスクリプトがロードされ、設定したアクティブ／非アクティブ制御が動作します。
ScriptRunnerのバグは以下の課題で報告されています。2018−05−08現在、まだ未解決ですね…
https://productsupport.adaptavist.com/browse/SRJIRA-2733 - Kaori Komori
試しにカスタマーのアカウントでログインして動作確認したところ、
バグ報告通り、事象が再現しました。コンポーネントがDisable表示されない。
400エラー発生。
確認した結果、
ServiceDeskプロジェクトのプロジェクトロールが管理者、またはServiceDeskTeamの場合はスクリプトが正常にロードされ、プロジェクトロールがCustomer、または未登録の場合はスクリプトが正常にロードされませんでした。 - Kengo Ohsaki
機能が使えねーと同じ不具合…。
＼(^o^)／オワタ
- Kaori Komori
どこまで響くかわかりませんが、早期改修を願う方は
下記サイトにSignupしてLet's Vote✩ - Kengo Ohsaki
Kaori Komori-san,
不具合課題に書いてある回避策（atlassian-addons-project-accessグループを作成して、カスタマーにそのグループを設定、JSDプロジェクトに設定している権限スキームのBrowse Projectにatlassian-addons-project-accessグループを追加）を応用して変な対応策ですが
JSDプロジェクトに設定している権限スキームのBrowse Projectに「報告者」フィールドを設定すれば動くようになりました。
カスタマーにアプリケーションの権限は付与してないので、ライセンスも消費しません。
また、Jira Service Deskでは基本的にカスタマーが報告者になるため、問題もないと思います。
不具合課題に書いてある回避策でも直ると思うのですが（グループ名は任意でOK）
カスタマーのユーザー取り込みを ADと同期してたりすると自由にグループ作って、設定することができないこともあるので、この方法が一番簡単かと思います。
- Kaori Komori
情報ありがとうございます。
ユーザにプロジェクトの閲覧権限明示的に付与することにより、問題が回避できるんですね。
元々、プロジェクトの閲覧権には、”サービスデスク顧客－ポータルアクセス”が設定されているのですが、Behavioursでこの辺の判定がうまくできていないということでしょうか…いただいた情報の通り、プロジェクトの閲覧権に報告者を設定すると、想定通りスクリプトが動きました。
確かにポータルで質問をリクエストを起票すると、ログインユーザ＝報告者となりますものね。リクエストの入力画面でのみ制御が必要な場合（JSDってこれ以外Behavioursで制御するような部分って無いですよね）、
不具合報告のコメントに出ていたワークアラウンド（グループを作ってカスタマを追加）より、シンプルで良いですね。 - Kengo Ohsaki
Kaori Komori-san,
元々、プロジェクトの閲覧権には、”サービスデスク顧客－ポータルアクセス”が設定されているのですが、Behavioursでこの辺の判定がうまくできていないということでしょうか…
はい。根本的にはBehavioursが内部で使っているJSDのAPIの不具合？にも思えますね…。
そのため、プロジェクトの閲覧権限（Browse Project）に報告者を設定することで
以下ナレッジベースの仕様不具合を意図的に起こしてます。
プロジェクトの閲覧権限（Browse Project）に報告者、担当者、ユーザーピッカーフィールドを設定すると、Jira全員にプロジェクトの存在（課題は見えない）が見えてしまう問題で
報告者、担当者、ユーザーピッカーのフィールドの値は、プロジェクト毎に固定ではなく課題ごとに異なり、かつその値は課題作成時点で確定するもので、プロジェクト閲覧権限が正常に判断ができなくなり、Jira全員にプロジェクトの存在（課題は見えない）が見えてしまう…というプロジェクト閲覧権限に設定できること自体が仕様不具合では？的なのようなものです。
今回はこの不具合を悪用して、回避策にしてみた感じです…。
想定通りうまくいきましたけどね…。
→ カスタマー権限はそもそもアプリケーションアクセス権限がないので設定変更による影響なし。基本的にログインユーザ＝報告者。代理人報告としてもカスタマー権限以上である。
→ エージェントもこの設定でも影響なし。
→ 対象JSDプロジェクトのコラボレータもこの設定でも影響なし。
→ 対象JSDプロジェクトのコラボレータではないけど、Jira Core、Jira Softwareのライセンスを持っているユーザーが、プロジェクトの存在が見えてしまう。但し、自分が報告者になっている課題以外は見れないので問題はない。
本質的にはアドオン側で何か対応するかしてもらうのを待ったほうが良いですかね。
- Kaori Komori
詳細な説明、ありがとうございます。
プロジェクトの閲覧権限（Browse Project）に報告者、担当者、ユーザーピッカーフィールドを設定すると、Jira全員にプロジェクトの存在（課題は見えない）が見えてしまう
プロジェクトの存在自体を隠す必要があるようなケースだとこの設定は要注意ですね。
勉強になりました！ - Kaori Komori
カスタマーポータルでEnable/Disable制御が動作しない問題について、
原因となっていたバグが5月31日リリースの5.4.7で修正されておりますヽ(=´▽`=)ﾉBehaviours do not load (HTTP 400 error) on SD support portal for some users
- Kaori Komori
Script runner 5.4.7、JSDプロジェクト（デフォルト設定）、ユーザはcustomer（ライセンスとの紐付けなし）で、
BehavioursによるフィールドのEnable/Disable制御が想定どおり動作しました。
コメントを追加...
カスタマーポータルのリクエスト画面で項目のEnable／Disable制御はできますか？