# Jira Service Desk

Jira Service Desk (opens new window)は、チームが優れたサービス体験を提供し、従業員や顧客が迅速にヘルプを得ることができるようにします。これにより、顧客と従業員の両方が直感的なセルフサービスポータルを提供され、迅速にヘルプを得るための1つの場所を提供されます。

# APIバージョン

Jira Service DeskコネクターはJira Service Desk Cloud REST API (opens new window)を使用しています。

# サポートされているエディションとバージョン

Jira Service Deskコネクターは、クラウドおよびオンプレミスの両方のインスタンスと、7.x以降のバージョンと互換性があります。

# WorkatoでJira Service Deskに接続する方法

Jira Service Deskに接続する方法は3つあります。APIトークンパスワードによる基本認証、およびOAuth 2.0です。

2018年12月1日以降、AtlassianはJira Service Desk(クラウドのみ)でのパスワードによる基本認証を廃止し、APIトークンを推奨しています。オンプレミスのJira Service Deskには影響はありません。

APIトークンまたはOAuth 2.0を使用してWorkatoに接続することを強くお勧めします。

# APIトークン

APIトークンはJira Service Deskとの認証の主な方法です。オンプレミスのJira Service Deskでは、パスワードによる基本認証のみを使用できます。

APIトークン認証 APIトークン認証

  • 接続名 このJira Service Desk接続に一意の名前を付けて、接続されているJira Service Deskインスタンスを識別します。

  • ホスト名 Jira Service Deskにログインするために使用する完全なJira Service DeskインスタンスのURL。

  • APIトークン認証を使用しますか? APIトークンを使用して認証する場合は、「はい」に設定します。その後、メールアドレスとAPIトークンを提供する必要があります。パスワードによる基本認証を使用して認証する場合は、「いいえ」に設定します。

  • メールアドレス WorkatoにリンクするためのJira Service Deskアカウントのメールアドレス。

  • APIトークン AtlassianアカウントからAPIトークンを作成するには:

  • このアプリはプライベートネットワーク内ですか? オンプレミスのJira Service Deskインスタンスに接続するには、オンプレミスエージェント (opens new window)をセットアップします。オンプレミスアクセス機能を使用できるかどうかは、Workatoに申し込まれたプランに依存します。

# OAuth 2.0

OAuth 2.0認証 OAuth 2.0認証

OAuth 2.0を介して認証する場合は、次の手順に従ってください:

  1. 認証タイプとしてOAuth 2.0を選択し、Jira Service Deskのサブドメインを入力します。
  2. 詳細設定で、要求する認可スコープを選択することもできます。それ以外の場合、Workatoはデフォルトで以下のスコープを要求します:
    • read:jira-user
    • read:jira-work
    • write:jira-work
    • manage:jira-project
    • manage:jira-project
    • manage:jira-configuration
    • manage:jira-webhook
    • read:servicedesk-request
    • write:servicedesk-request
    • manage:servicedesk-customer
  3. 「接続」をクリックし、別のウィンドウでアカウントのユーザー名とパスワードを使用してJira Service Deskインスタンスにログインするように求められます。
  4. WorkatoのJira Service Deskインスタンスへのアクセスを許可します。

# パスワードによる基本認証

パスワードによる基本認証を使用してJira Service Deskに認証することができます。

2018年12月1日以降、AtlassianはJira Service Desk(クラウドのみ)でのパスワードによる基本認証を廃止し、APIトークンを推奨しています。オンプレミスのJira Service Deskには影響はありません。

基本認証パスワード認証 基本認証パスワード認証

  • 接続名 このJira Service Desk接続に一意の名前を付けて、接続されているJira Service Deskインスタンスを識別します。

  • ホスト名 Jira Service Deskにログインするために使用する完全なJira Service DeskインスタンスのURL。

  • APIトークン認証を使用しますか? パスワードによる基本認証を使用して認証する場合は、「いいえ」に設定します。その後、ユーザー名とパスワードを提供する必要があります。APIトークンを使用して認証する場合は、「はい」に設定します。

  • ユーザー名 Jira Service Deskに接続するためのユーザー名。

  • パスワード Jira Service Deskに接続するためのパスワード。

  • このアプリはプライベートネットワーク内ですか? オンプレミスのJira Service Deskインスタンスに接続するには、オンプレミスエージェント (opens new window)をセットアップします。オンプレミスアクセス機能を使用できるかどうかは、Workatoに申し込まれたプランに依存します。

# 接続に必要な役割と権限

Jira Service Desk インスタンスへのログインアクセス権を持っている Jira Service Desk ユーザーは、その認証情報を使用して Workato に接続できます。ただし、統合のために別のユーザー(Jira Service Desk 管理者のグローバル権限を持つ)を作成することをお勧めします。

# People

ユーザーは、2つの方法でプロジェクトに追加できます(プロジェクト設定 → ユーザーを参照):

  1. 特定のユーザーを検索して選択し、そのユーザーのプロジェクトロールを指定します。 People project rolesユーザーJan Donyadaのプロジェクトロールの選択

    プロジェクトロールは、ユーザーを機能的な役割に関連付けることができます。たとえば、組織がすべてのソフトウェア開発の問題をクローズする前に「QA」の人物によるテストを要求する場合、次のようにすることができます:

    • 「QA」というプロジェクトロールを作成します。
    • 「ソフトウェア開発」という名前の権限スキームを作成し、「QA」ロールに「問題をクローズする」権限を割り当てます。
    • 「ソフトウェア開発」の権限スキームをすべてのソフトウェア開発プロジェクトに関連付けます。
    • 各ソフトウェア開発プロジェクトに、QAエンジニアを追加し、「QA」プロジェクトロールを割り当てます。
  2. グループを検索し、グループのプロジェクトロールを指定します。 People project groupJira管理者グループのプロジェクトロールの選択 「グループ」には複数のメンバーが含まれます。グループはプロジェクトロールと似ていますが、1つの重要な違いがあります。グループのメンバーシップはグローバルであり、プロジェクトロールのメンバーシップはプロジェクト固有です。また、グループのメンバーシップはJira管理者のみが変更できますが、プロジェクトロールのメンバーシップはプロジェクト管理者が変更できます。

# Issue Security Schemes

Issue security schemes (opens new window)は、各プロジェクトに作成および追加でき、プロジェクトの問題を表示および編集できるユーザーを制御することができます。

スキームには複数のセキュリティレベルがあり、各セキュリティレベルにユーザーまたはユーザーグループを割り当てることができます。これにより、適切なセキュリティレベルに割り当てられたユーザーのみが問題を表示できるようになります。

プロジェクトに定義された問題のセキュリティスキームがある場合、リンクされたJiraアカウントはセキュリティスキームの適切なセキュリティレベルのメンバーである必要があります。通常、セキュリティレベルのメンバーには次のようなものがあります:

  • 個々のメンバー
  • グループ
  • プロジェクトロール
  • '報告者'、'プロジェクトリード'、'現在の担当者'などの問題ロール
  • 'Anyone'(匿名アクセスを許可するため)

以下の例では、問題のセキュリティスキームには、特定のユーザー、グループ、およびプロジェクトロールのみがアクセスできるセキュリティレベルが定義されています。

Issue security scheme ユーザー「Jan Donyada」、Jira管理者グループのユーザー、および「QA」プロジェクトロールのユーザーのみが、'Top-secret'セキュリティレベルで定義された問題にアクセスできます

# Permission Schemes

プロジェクトの権限は、Jira管理者によって特定のプロジェクトに割り当てられる権限スキーム内で作成されます。

権限は、問題の作成、問題の編集、問題の割り当てなどの特定のアクションに対して付与することができます。権限は、プロジェクト設定 → 権限を選択することで見つけることができます。

各権限は以下の範囲で付与することができます:

  1. プロジェクトロール
  2. アプリケーション(JIRA、JIRA Service Deskなど)
  3. グループ
# 1. プロジェクトロール

プロジェクトに関連付けられた権限スキームが特定のアクションに対してロール固有の権限を定義している場合、リンクされたJiraアカウントは同じロールに割り当てられている必要があり、Workatoのレシピでそのアクションを使用するために承認される必要があります。

たとえば、以下のプロジェクト権限スキームでは、「QA」ロールのみが「問題をクローズする」アクションを実行できるように許可されています。 QA role

したがって、Workatoのレシピが「問題をクローズする」アクションを実行する場合、リンクされたJiraアカウントはアクションを承認するために「QA」の役割も割り当てられている必要があります。

# 2. アプリケーションアクセス

アプリケーションアクセス設定を使用すると、どの人物がどの製品にアクセスできるかを制御することができます。サイトに1つの製品のみがある場合(たとえば、ConfluenceのみまたはJiraのみのインスタンスがある場合)、ユーザーはサインアップ時にその製品へのアクセスが自動的に許可されます。

Application permission schemes

WorkatoのレシピがJira Service Deskインスタンスで特定のアクションのみを実行する必要がある場合、それらのアクションには必ずJira Service Deskが選択されている必要があります。Jira Service Deskのみ Jira Service Deskのユーザーのみが課題を割り当てることが許可されています

同様に、WorkatoのレシピがJira Softwareの特定のアクションのみを実行する場合、それらのアクションにはJira Softwareが選択されている必要があります。

WorkatoのレシピがJira Service DeskとJira Softwareの両方で特定のアクションを実行する場合、それらのアクションにはログインしているユーザーが選択されている必要があります。

ログインしているユーザー Jira Service DeskまたはJira Softwareのログインしているユーザーは、課題を割り当てることが許可されています

# 3. グループ

プロジェクトに関連付けられた権限スキームが特定のアクションに対してグループ固有の権限を定義している場合、リンクされたJira Service Deskアカウントは、Workatoのレシピでそれらのアクションを使用するためにそのグループのメンバーである必要があります。 Jira管理者グループ Jira管理者グループはスプリントの管理が許可されています

# Jira権限ヘルパー

Jira権限ヘルパーを使用して、ユーザーが特定のプロジェクトやフィールドを表示/編集できない理由を調べることができます。

Jira権限ヘルパー

これを利用するには、Jira Service DeskインスタンスへのJira管理者アクセス権が必要です。詳細については、Jiraの権限ヘルパーガイド (opens new window)を参照してください。

# トリガーとアクション

他の章を閲覧することができます:

# Jira Service Deskのアクション


Last updated: 2024/2/13 16:59:53