次の方法で共有


作業追跡のアクセス許可の設定

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

作業の追跡を効果的に管理するには、特定の オブジェクト、プロジェクト、またはコレクションのユーザーまたはグループに特定のアクセス許可を割り当てます。 また、特定のユーザーまたはグループに適用されるプロセスまたはプロジェクトに対してカスタム ルールをし、それに応じてアクションを制御することもできます。 ほとんどの機能では、包括的なアクセスを許可し、シームレスで効率的な作業追跡エクスペリエンスを確保するプロジェクトの Contributors グループにユーザーを追加することをお勧めします。

Note

パブリック プロジェクトの場合、利害関係者アクセスにより、ユーザーは作業追跡機能にアクセスし、Azure Pipelines に完全にアクセスできるようになります。 詳細については、「利害関係者アクセスクイック リファレンス」を参照してください。

前提条件

作業追跡のアクセス許可を設定するには、 Project Administrators グループのメンバーであるか この記事で説明されているように、作業追跡領域を管理するための明示的なアクセス許可が必要です。

プロセスのアクセス許可を設定するには、 Project コレクション管理者 グループのメンバーであるか コレクション プロセスを編集するための明示的なアクセス許可を持っている必要があります。

作業追跡のロールとアクセス許可レベルを理解する

次の表は、オブジェクト、プロジェクト、またはコレクション レベルで設定できるさまざまなアクセス許可をまとめたものです。 チーム管理者ロールは、チーム リソースを追加および変更するためのアクセス権を提供します。 また、この記事の「ボード、バックログ、スプリント、配信計画、テスト管理、クエリの既定のアクセス許可」も参照してください。


ロールまたはアクセス許可レベル

機能領域セット


チーム管理者ロール
チーム管理者を追加する


オブジェクト レベルのアクセス許可


プロジェクト レベルのアクセス許可


プロジェクト コレクション レベルのアクセス許可
コレクション レベルで設定できるすべてのアクセス許可が含まれます。


ボード、バックログ、スプリントの既定のアクセス許可

ボードの既定のアクセス許可

タスク

Readers

寄稿者

チーム管理者
プロジェクト管理者

ボードを表示して作業項目を開く

✔️

✔️

✔️

ボードに作業項目を追加し、ドラッグ アンド ドロップで状態を更新する

✔️

✔️

ドラッグ アンド ドロップで作業項目の順序変更や、子項目の親の再設定を行う。カードのフィールドを更新する

✔️

✔️

ボードに作業項目を追加する。ドラッグ アンド ドロップで状態の更新、順序変更、または子項目の親の再設定を行う。カードのフィールドを更新する

✔️

✔️

チェックリストに子項目を追加する

✔️

✔️

スプリントに割り当てる (カードのフィールドから)

✔️

✔️

ボードの設定を構成する

✔️

バックログの既定のアクセス許可

タスク

Readers

寄稿者

チーム管理者
プロジェクト管理者

バックログを表示して作業項目を開く

✔️

✔️

✔️

作業項目をバックログに追加する

✔️

✔️

一括編集機能を使用する

✔️

✔️

バックログ項目に子項目を追加する。バックログの優先順位付けまたは順序変更を行う。[マッピング] ペインを使って項目の親を設定する。[計画] ペインを使ってスプリントに項目を割り当てる

✔️

✔️

チームの設定、バックログ レベル、バグの表示、稼働日の休暇を構成する

✔️

スプリントの既定のアクセス許可

タスク

Readers

寄稿者

チーム管理者プロジェクト管理者

スプリント バックログ、タスクボード、開いている作業項目を表示する

✔️

✔️

✔️

スプリント バックログまたはタスクボードに作業項目を追加する

✔️

✔️

スプリント バックログまたはタスクボードの優先順位付けまたは順序変更を行う。バックログ項目に子項目を追加する。[計画] ペインを使ってスプリントへの項目の割り当てを変更する

✔️

✔️

チームのキャパシティと作業の詳細を表示する

✔️

✔️

チームのキャパシティを設定する

✔️

一括編集機能を使用する

✔️

✔️

チームのスプリントを定義する

✔️

子ノードの作成、領域または反復パスの下の作業項目の変更

エリア パスのアクセス許可を使用すると、作業項目、テスト ケース、またはそれらの領域に割り当てられたテスト 計画を編集または変更するためのアクセスを管理できます。 ユーザーまたはグループにアクセス権を制限できます。 また、プロジェクトの領域またはイテレーションを追加または変更できるユーザーのアクセス許可を設定することもできます。

Note

Area Paths または Iteration Paths を作成または編集する権限を持つプロジェクト メンバーは、チーム Area PathsIteration Paths を設定できません。 チーム設定を構成するには、team 管理者ロールに追加するかProject Administrators グループのメンバーである必要があります

プロジェクトの領域とイテレーションの両方を定義するには、次の手順を実行します。

  1. プロジェクトの設定>プロジェクト構成>Boardsを選択し、 Areas または Iterations を選択して、エリア パスまたは反復パスを変更します。

    [プロジェクトの設定]、[作業]、[プロジェクトの構成] を開いている様子を示すスクリーンショット。

  2. 管理するノードの ... コンテキスト メニューを選択し、 Security を選択します。

    [エリア パス] のコンテキスト メニューのスクリーンショット。[セキュリティ] を選択します。

  3. グループまたはプロジェクト メンバーを選択し、アクセス許可の設定を変更します。 ユーザーまたはグループを追加するには、検索ボックスにユーザー名を入力します。

    たとえば、ここでは、 Disallow アクセス グループを追加し、このグループの許可されていないメンバーに、 Account Management 領域パスで作業項目を表示、変更、または編集する機能を追加しました。

    [エリア パス] ノードの [セキュリティ]、[選択したグループ]、[アクセス許可の拒否] の設定のスクリーンショット。

    アクセス許可には、 DenyAllow の 2 つの明示的な承認状態を指定できます。 さらに、アクセス許可は、他の 3 つの状態のいずれかに存在できます。 詳細については、「 アクセス許可、アクセス、およびセキュリティ グループについてを参照してください。

  4. (省略可能)[ 継承を無効にするには、 スライダーを選択します。 Inheritance を無効にすると、継承されたすべてのアクセス許可が明示的なアクセス制御エントリ (ACE) として保持されます。

  5. 完了したら、ダイアログを閉じます。 変更内容は自動的に保存されます。

プロジェクトの領域とイテレーションの両方を定義するには、次の手順を実行します。

  1. (1) プロジェクト設定> (2) プロジェクト構成> (3) Areas を選択します。

    オンプレミス サーバーのプロジェクト設定>Work>Project 構成を開くシーケンスのスクリーンショット。

  2. 管理するノードの ... コンテキスト メニューを選択し、 Security を選択します。

    [エリア パス] のコンテキスト メニューのスクリーンショット。[セキュリティ]、[Azure DevOps Server 2020] の順に選択します。

  3. グループまたはチーム メンバーを選択し、アクセス許可の設定を変更します。 ユーザーまたはグループを追加するには、検索ボックスにユーザー名を入力します。

    次の例では、 Disallow アクセス グループを追加し、このグループの許可されていないメンバーに、カスタマー サービス領域パスの作業項目を表示、変更、または編集する機能を追加しました。

    エリア パス ノードのセキュリティ、選択したグループ、および拒否アクセス許可の設定、Azure DevOps Server 2022 以前のバージョンのスクリーンショット。

    アクセス許可には、 DenyAllow の 2 つの明示的な承認状態を指定できます。 アクセス許可は、他の 3 つの状態のいずれかに存在することもできます。 詳細については、「 アクセス許可、アクセス、およびセキュリティ グループについてを参照してください。

  4. (省略可能)継承を無効にするには、 InheritanceOff に切り替えます。 Inheritance を無効にすると、継承されたすべてのアクセス許可が明示的なアクセス制御エントリ (ACE) として保持されます。

  5. 完了したら、ダイアログを閉じます。 変更内容は自動的に保存されます。

作業項目の既定のアクセス許可

Note

作業項目の種類を変更したり、プロジェクト コレクション内の別のプロジェクトに作業項目を移動したりできます。 これらの機能を使用するには、データ ウェアハウスが無効になっている必要があります。 データ ウェアハウスが無効になっているときは、Analytics サービスを使ってレポートのニーズをサポートできます。 データ ウェアハウスを無効にする方法の詳細については、「データ ウェアハウスとキューブを無効にする」を参照してください。

タスクまたはアクセス許可

Readers

寄稿者

プロジェクト管理者


このノードの作業項目を表示する (区分パスのアクセス許可)

✔️

✔️

✔️

このノードの作業項目を編集する (区分パスのアクセス許可)

✔️

✔️

このノードの作業項目のコメントを編集する (区分パスのアクセス許可)

✔️

✔️

タグ定義の作成

✔️

✔️

作業項目の種類を変更する (プロジェクト レベルのアクセス許可)

✔️

✔️

このプロジェクトから作業項目を移動する (プロジェクト レベルのアクセス許可)

✔️

✔️

作業項目をメールで送信する

✔️

✔️

✔️

作業項目テンプレートを適用する

✔️

✔️

作業項目を削除して復元する (プロジェクト レベルのアクセス許可) (ごみ箱から復元可能)

✔️

✔️

作業項目を完全に削除する (プロジェクト レベルのアクセス許可)

✔️

フィードバックを提供する (Microsoft Feedback Client を使用)

✔️

✔️

✔️

✔️

注意

作業項目は、それらに適用されるルールの対象となります。 ユーザーまたはグループのメンバーシップに基づく条件付きルールは、Web ブラウザー用にキャッシュされます。 作業項目の更新が制限されている場合は、これらのルールのいずれかが適用されている可能性があります。 自分には当てはまらない問題が発生したと思われる場合は、作業項目フォームでの IndexDB のキャッシュの問題に関する記事をご覧ください。 詳細については、「規則と規則の評価」を参照してください。

カスタム ルールを使用します

カスタム ルールはアクセス許可を制御しませんが、ユーザーが作業項目を変更できるか、作業項目フィールドの値を設定できるかに影響します。 Azure Boards では、ビジネス ワークフローをサポートする次の作業追跡のカスタマイズがサポートされています。

カスタマイズ
作業項目の作成、状態の変更、および指定された状態にルールを適用します。 - フィールドを読み取り専用にする
- フィールドを必須にする
フィールド値が空の場合、特定の値に設定されている場合、または値に変更または変更されていない場合は、ルールを適用します。 - フィールドが空の場合、または特定の条件を満たしている場合はフィールドの値をクリアします
- フィールドが空であるか、特定の条件を満たしている場合は、フィールドの定義済みの値を設定します
- フィールドの値を別のフィールドにコピーします
- 特定の条件または値に基づいてフィールドを非表示にする
特定の状態から作業項目を移動できる状態を指定するルールを適用します。 - 状態の変更に基づいて作業項目を再割り当てする
- 作業項目が "状態 A" から "状態 B" にのみ移行できることを指定します
- 子作業項目の状態変更に基づいて親作業項目の状態遷移を管理します
作業項目を変更するユーザーのユーザーまたはグループ メンバーシップに基づいてルールを適用します。 グループが作業項目を作成すること、作業項目を閉じた状態または完了した状態に移行すること、またはフィールドの値を変更することを制限するルールを指定する

システム フィールドにカスタム ルールを適用するには、いくつかの制限があります。 たとえば、システム フィールドであるため、 Area Path または Iteration Path の値を設定またはクリアするルールを指定することはできません。 詳細については、「 ルールとルールの評価 および サンプル ルールのシナリオを参照してください。

クエリまたはクエリ フォルダーに対するアクセス許可を設定する

オブジェクト レベルでクエリ フォルダーまたはクエリを追加または編集できるユーザーを指定できます。 クエリまたはクエリ フォルダーのアクセス許可を管理するには、クエリまたはフォルダーの作成者であるか、プロジェクト管理者またはプロジェクト コレクション管理者グループのメンバーであるか、オブジェクトの Security ダイアログから明示的なアクセス権を付与されている必要があります。

[クエリ フォルダーのアクセス許可] ダイアログ

クエリ フォルダーの [アクセス許可] ダイアログのスクリーンショット。

クエリ フォルダー、Azure DevOps Server 2022 以前のバージョンの [アクセス許可] ダイアログのスクリーンショット。

詳細については、「 マネージド クエリを作成して作業項目を一覧表示、更新、またはグラフ化するを参照してください。

クエリの既定のアクセス許可

ヒント

既定では、共同作成者は共有クエリを作成および保存できません。 プロジェクト管理者には、チームごとにクエリ フォルダーを作成し、チーム管理者またはチーム グループにフォルダーを管理するためのクエリのアクセス許可を付与することをお勧めします。 共有クエリまたはフォルダーの名前を変更または移動するには、削除アクセス許可と、クエリの移動先フォルダーに対する投稿アクセス許可が必要です。 詳細については、「クエリとクエリ フォルダーの権限を設定する」を参照してください。

タスク

Readers

寄稿者

プロジェクト管理者


マネージド クエリを表示および実行し、クエリ グラフを表示する

✔️

✔️

✔️

マネージド マイ クエリとクエリ グラフを作成して保存する

✔️

✔️

共有クエリ、グラフ、フォルダーを作成、削除、保存する

✔️

アドホック検索 はセマンティック検索エンジンを利用します。

作業項目タグのアクセス許可を設定する

既定では、共同作成者グループのすべてのユーザーは、タグを作成し、作業項目に追加することができます。 この機能を制限するようにグループまたはユーザーのアクセス許可を設定するには、プロジェクト レベルで [タグ定義の作成][拒否] に設定します。 方法については、プロジェクト レベルのグループのアクセス許可レベルの変更に関する記事をご覧ください。

配信プランのアクセス許可を管理する

配信計画は、プロジェクト内のオブジェクトです。 共有クエリやクエリ フォルダーのアクセス許可を管理する方法と同様に、各プランのアクセス許可を管理できます。 配信計画の作成者と、プロジェクト コレクション管理者グループとプロジェクト管理者グループのすべてのメンバーは、プランの編集、管理、削除を行う権限を持ちます。

プライベート プロジェクト Stakeholder アクセス権を付与されたユーザーは配信プランにアクセスすることはできませんが、パブリック プロジェクトに対して Stakeholder アクセス権を付与したユーザーは、 Basic アクセス権を付与された通常の共同作成者と同じアクセス権を持ちます。 利害関係者と基本アクセスの比較グラフについては、 Feature Matrixを参照してください。

デリバリー計画のアクセス許可を編集するには、計画の作成者、プロジェクト管理者またはプロジェクト コレクション管理者グループのメンバーであるか、計画の [セキュリティ] ダイアログで明示的なアクセス許可を付与されている必要があります。

  1. [Boards] > [デリバリー計画] を開きます。

    配信プランを開くために選択するための一連のボタンを示すスクリーンショット。

  2. 特定の計画を管理または編集するためのアクセス許可をグループまたはユーザーに付与するには、[その他のオプション] を選択して計画の [セキュリティ] ダイアログを開きます。

    プランの [アクセス許可] ダイアログを示すスクリーンショット。

  3. アクセス許可を付与またはアクセスを制限するユーザー、チーム グループ、またはその他のセキュリティ グループを追加します。 詳細については、「プロジェクト レベルのアクセス許可を変更する」を参照してください。 既定では、管理者以外のユーザーはプランを削除または編集できません。

  4. ユーザーまたはグループを選択した状態で、必要なアクセス許可を [許可] に設定します。 [管理][許可] に設定すると、ユーザーは計画のアクセス許可を管理できます。

    配信プランの [アクセス許可] ダイアログの例を示すスクリーンショット。

  5. 完了したら、ダイアログを閉じます。 変更内容は自動的に保存されます。

  1. [Boards] > [計画] を開きます。 詳細については、「 Review team delivery plans」を参照してください。

  2. 特定の計画を管理または編集するためのアクセス許可をグループまたはユーザーに付与するには、 アクション アイコンを選択して計画の [セキュリティ] ダイアログを開きます。

    赤いボックスで強調表示されているプランのアクセス許可の [セキュリティ] ボタンを示すスクリーンショット。

  3. アクセス許可を付与またはアクセスを制限するユーザー、チーム グループ、またはその他のセキュリティ グループを追加します。 詳細については、「プロジェクト レベルのアクセス許可を変更する」を参照してください。 既定では、管理者以外のユーザーは計画を削除または編集できません。

  4. ユーザーまたはグループを選択した状態で、必要なアクセス許可を [許可] に設定します。 [管理][許可] に設定すると、ユーザーは計画のアクセス許可を管理できます。

    たとえば、ここでは、計画を編集するためのアクセス許可を Raisa に付与します。

    配信プランのアクセス許可ダイアログを示すスクリーンショット。

  5. 完了したら 保存します。

配信プランの既定のアクセス許可

タスク

Readers

寄稿者

チーム管理者
プロジェクト管理者

配信プランを表示する

✔️

✔️

✔️

配信プランを作成、編集、または削除します。共同作成者は、作成したプランのみを編集または削除できます

✔️

✔️

配信プランのアクセス許可を管理し、共同作成者は作成したプランのアクセス許可のみを管理できます

✔️

✔️

作業項目を移動または完全に削除する

既定では、プロジェクト管理者と共同作成者は、作業項目の種類を変更し、作業項目を Recycle Bin に移動することで削除できます。 作業項目とテスト成果物を完全に削除できるのは、プロジェクト管理者だけです。 プロジェクト管理者は、必要に応じて他のチーム メンバーにアクセス許可を付与できます。

たとえば、プロジェクト管理者として、作成したユーザー、チーム グループ、またはその他のグループにこれらのアクセス許可を付与できます。 プロジェクトの [セキュリティ] ページを開き、アクセス許可を付与するユーザーまたはグループを選択します。 プロジェクト レベルの Security にアクセスする方法については、「 Change プロジェクト レベルのアクセス許可を参照してください。

Note

このプロジェクトの Move 作業項目 アクセス許可には、プロジェクトの Inherited プロセス モデル が必要です。

次の例では、チーム管理者ロールに割り当てられているメンバー、およびチーム管理者グループに属しているメンバーに、作業項目を別のプロジェクトに移動し、作業項目を完全に削除するためのアクセス許可を付与しました。

カスタム セキュリティ グループのプロジェクト レベルのアクセス許可の設定を示すスクリーンショット。

テスト計画とテスト スイートを管理する

前のセクションで設定したプロジェクト レベルのアクセス許可に加えて、チーム メンバーには、エリア パスに設定されているテスト成果物を管理するためのアクセス許可が必要です。

エリア パスの Security ページを開き アクセス許可を付与するユーザーまたはグループを選択します。

プロジェクトに対して開いているエリア パスのアクセス許可を示すスクリーンショット。

Manage テスト プランおよび Manage テスト スイートのアクセス許可を Allow に設定します。

[テストプランとスイートを許可する] に設定されたアクセス権を示すスクリーンショット。

テスト機能セットにフル アクセスするには、 アクセス レベルを Basic + Test Plans に設定する必要があります。 Basic アクセス権を持ち、作業項目の完全な削除とテスト成果物の管理を行うためのアクセス許可を持つユーザーは、孤立したテスト ケースのみを削除できます。

テスト管理の既定のアクセス許可

テスト 計画、テスト スイート、テスト ケース、その他のテスト成果物は、手動および探索的テストをサポートする特定の作業項目の種類です。 詳細については、「 プロジェクト レベルでテスト権限を設定するを参照してください。

権限

Level

Readers

寄稿者

プロジェクト管理者

テストの実行を表示する

プロジェクト レベル

✔️

✔️

✔️

テスト実行の作成
テスト実行の削除

プロジェクト レベル

✔️

✔️

テスト構成の管理
テスト環境の管理

プロジェクト レベル

✔️

✔️

タグ定義の作成
作業項目を削除して復元する

プロジェクト レベル

✔️

✔️

作業項目を完全に削除

プロジェクト レベル

✔️

このノードの作業項目を表示します

区分パス

✔️

✔️

✔️

このノードの作業項目を編集します
テスト計画を管理する
テスト スイートの管理

区分パス

✔️

✔️

Note

Change 作業項目の種類アクセス許可は、テスト固有の作業項目には適用されません。 作業項目フォームからこの機能を選択した場合でも、作業項目の種類の変更は許可されません。

Web ベースのテスト ケース管理とテスト実行の領域アクセス許可は、次のアクションへのアクセスを制御します。

Manage テスト スイートアクセス許可を使用すると、ユーザーは次のタスクを実行できます。

  • テスト スイートの作成と変更
  • テスト スイート間でテスト ケースを追加または削除する
  • テスト スイートに関連付けられているテスト構成を変更する
  • テスト スイートを移動してスイート階層を変更する

Manage テスト プランアクセス許可を使用すると、ユーザーは次のタスクを実行できます。

  • テスト 計画の作成と変更
  • テスト 計画に対してテスト スイートを追加またはテストから削除する
  • ビルドやテストの設定などのテスト 計画のプロパティを変更する

継承されたプロセスをカスタマイズする

既定では、プロジェクト コレクション管理者のみがプロセスを作成および編集できます。 ただし、これらの管理者は、特定のユーザーに対してコレクション レベルで [プロセスの作成][プロセスの削除] 、または [プロセスの編集] アクセス許可を明示的に設定することで、他のチーム メンバーにアクセス許可を付与できます。

プロセスをカスタマイズするには、特定のプロセスのユーザー アカウントに [プロセスの編集] アクセス許可を付与する必要があります。

Note

Project-Scoped Users グループに追加されたユーザーは、Limit ユーザーの可視性と特定のプロジェクトへのコラボレーションプレビュー機能が組織に対して有効になっている場合、プロセス設定にアクセスできません。 セキュリティ関連の重要なコールアウトを含む詳細については、「 組織の管理」、プロジェクトのユーザーの可視性の制限などを参照してください

  1. […] 継承されたプロセスのコンテキスト メニューを選択し、 Security を選択します。 このページを開くには、「 継承されたプロセスを使用してプロジェクトをカスタマイズするを参照してください。

    開いている [プロセス]、[セキュリティを開く] ダイアログを示すスクリーンショット。

  2. ユーザー名を入力し、該当するアクセス許可を Allow に設定して終了します。 ページは自動的に保存されます。

    プロセス ダイアログのアクセス許可を示すスクリーンショット。

Note

プロセスは、作成、編集、削除のために個別の ACL を持つセキュリティ保護可能なエンティティです。 プロジェクト コレクション管理者は コレクション レベルで継承されたプロセスを決定します。 継承された新しいプロセスは、作成者とプロジェクト コレクション管理者にフル コントロールを付与します。この管理者は、プロセス管理のために ACL を他のユーザーに割り当てることもできます。

作業項目のその他のアクセス オプション

制限をサポートするように作業項目の種類をカスタマイズするためのオプションの詳細については、「 Restrict アクセス、ユーザーまたはグループに基づいて作業項目の変更を制限するを参照してください。

チーム メンバーに追加のアクセス許可を付与する

チームが自律的に作業するには、既定では持っていないアクセス許可をチームに付与することができます。 推奨されるタスクには、次のアクセス許可をチーム管理者またはチーム リーダーに提供することが含まれます。

既定では、チーム メンバーはプロジェクト共同作成者グループのメンバーに付与されるアクセス許可を継承します。 このグループのメンバーは、ソース コードの追加と変更、テスト実行の作成と削除、作業項目の作成と変更を行うことができます。 Git プロジェクトでを行ったり他のチーム メンバーと共同作業を行ったり、チームのコード ベース (TFVC) に作業をチェックしたりできます。

チームの共同作成者に割り当てられている既定のアクセス許可のスクリーンショット。

オンプレミスのデプロイにレポートが含まれている場合は、それらのリソースにユーザーを追加します。 SQL Server レポートを表示または作成するためのアクセス許可を参照してください。