プロジェクト権限を管理する

Project permissions comprise permission schemes that Jira admins configure according to their projects' requirements and then assign to these projects. Project permissions can be granted to:

  • individual users
  • groups
  • project roles
  • issue roles such as Reporter, Project Lead, and Current Assignee
  • the Anyone group to allow anonymous access
  • a multi-user picker custom field
  • a multi-group picker custom field, which is either an actual group picker custom field or a multiselect list where values are group names

Some permissions depend on others to ensure that users can perform required actions. For example, if a user wants to be able to resolve an issue, they must be granted both the Transition Issue permission and the Resolve Issue permission. 

As a system admin or admin, you can manage project permissions, but you can't create new, custom permissions.

Learn more about the global permissions

Learn more about the difference between global and project permissions

On this page:

Some project permissions require product access. This means they're applicable only if your users have access to the Atlassian product associated with the permission. For example, if you give someone the permission to edit issues in a Jira Software project, they still require product access to Jira Software to use this permission.

If you add users to a role that grants particular permissions, make sure these users have product access to Jira Software (for software projects) or Jira Service Management (for service projects). Otherwise, your users will see a read-only version of the projects you want them to work on.

Only a Jira admin can grant individual product access. Learn more about product access

プロジェクト権限の概要

The following table lists different types of project permissions and user actions they allow. Note that project permissions can also be used in workflow conditions.


プロジェクト権限

説明

プロジェクトの管理

Jira のプロジェクトを管理する権限。これには、プロジェクト ロールのメンバーシッププロジェクト コンポーネントプロジェクトのバージョン、一部のプロジェクト詳細 (プロジェクト名、URL、プロジェクト リード、プロジェクトの説明) を編集する権限が含まれます。

Granting this permission alongside the Browse projects permission lets a user see the audit log for a specific project.

A user with the Administer Projects permission automatically becomes a project admin. Unlike Jira admins,  project admins can't manage multiple system configurations, including project permission schemes. 

Learn more about the differences between a project admin and Jira admin

プロジェクト管理の拡張

Gives the project administrator the ability to edit workflows and screens under certain conditions, as well as maintain their own workflows within predefined guardrails (data type recommendations for identifying potential risks and making decisions about your instance optimization).

プロジェクトのワークフロー編集に関する制限....
  • 他のプロジェクトと共有されていないワークフロー、およびシステム ワークフロー以外のワークフローである必要があります。
  • Only a status that already exists on the instance can be added to the workflow. The project admin can't create new statuses or edit existing ones.
  • プロジェクトの課題で使用されていないステータスを削除できます。
  • The project admin can create, update, or delete transitions. But they can't select or update a screen used by the transition nor edit and view a transition's properties, conditions, validators, or post-functions.
プロジェクトの画面編集に関する制限....
  • 既定のシステム画面以外の画面である必要があります。
  • 他のプロジェクトと共有されていない画面、およびワークフローのトランジション画面として使用されていない画面である必要があります。
  • The project admin can add, remove, and rearrange system fields.
  • The project admin can add, remove, and rearrange existing custom fields, but they can't create custom fields.
権限が無効になっているのに、プロジェクト管理者ワークフローを編集できるのはなぜですか?

When the Extended project admin permission is disabled, a project administrator may still be able to edit the Simplified Workflow by adding statuses that may not exist in the system. 

This is because the project admin is also listed as a board admin. Their changes to the Simplified Workflow will alter the project’s regular workflow. 

If you don't want this to happen, we recommend switching from the Simplified Workflow to the regular workflow. 

プロジェクトの閲覧

プロジェクトを参照する権限。課題ナビゲーターによって個別の課題を表示します (課題レベルのセキュリティによって制限されている課題を除く)。 

Many other permissions depend on this permission. For example, the Work on issues permission only works for users who also have the Browse projects permission.

Granting this permission alongside the Administer projects permission lets a user see the audit log for a specific project.

The Browse Projects permission may make your projects publicly visible on the internet

Here are a few important things you should remember about this permission.

The Browse projects permission may make your project details visible to all users in directories and while searching through Jira.

When you grant the permission to ReporterCurrent assignee, or Group custom field value, your project becomes visible to any logged in user on your Jira site.

Also, granting the Browse Projects permission to Anyone in your permission scheme means that issues from a project that uses this scheme become publicly viewable on the internet. You may legitimately want to grant public access to some projects and issues on your site, like in the case of a public bug tracker. Learn more about anonymous access

Use the Browse Projects permission to allow users only to view issues

To give users view-only access to issues:

  • Grant the Browse projects permission
  • Make sure your users don't have permissions of any other type

Users can also comment on issues or track work in them without editing issue details. To do this:

  • Grant the Browse projects permission
  • Grant the comments or time tracking permissions, depending on what you'd like to allow users
  • Make sure users don't have any issues permissions

スプリントの管理 (Jira Software ユーザーのみ使用可能)

次のスプリント関連アクションをボード上にあるすべてのプロジェクトに実行する権限。

アクション
  • スプリントを作成
  • スプリントを開始
  • スプリントを完了
  • スプリントを再オープン
  • 以降のスプリントを並び替え
  • スプリントの目標を追加
  • スプリントを削除
  • スプリント情報を編集 (スプリント名、目標、日付)
  • スプリント フッターを移動

When you have complex board filter queries, you should be careful with configuring the Manage sprints permission for users. For more information on the impact of complex filters and ways to simplify your filter query, see Using Manage Sprints permission for advanced cases.

スプリント作業の注意事項

一般的に、スプリント操作にはスプリントの管理権限が必要です。ただし、一部のスプリント操作 (スプリントへの課題の追加、スプリントからの課題の削除など) には、課題の予定と課題の編集の各権限が必要です。

スプリントに課題を追加する場合は、

  • サブタスクは親タスクと切り離して移動できません。
  • 課題はアクティブ スプリントか、今後のスプリントのどちらか 1 つにしか割り当てられません。アクティブ スプリントと今後のスプリントの両方に同時に課題は追加できません。
  • スプリントを作成したボードのフィルター クエリと課題が一致しない場合でも、任意の課題をアクティブ スプリント、または今後のスプリントに追加できます。この場合は次のようになります。
    • 課題はスプリントに割り当てられますが、フィルター クエリがその課題を除外するボード上では表示されません。
    • また、複数のボードにまたがるスプリント操作 (スプリントの開始やスプリントのクローズなど) は、スプリントが表示されるすべてのボード上にあるスプリントに影響を与えます。
    • 課題がどのアジャイル ボードのフィルター クエリとも一致しない場合、課題はスプリントにリンクされますがどのボードにも表示されません。
  • スプリントに割り当てられた課題がボードのフィルター クエリに一致する限り、スプリントはそれらのボードに表示されます。ボードの枚数は問いません。これは完了したスプリントにも適用されます。

詳細については、スプリントの計画を参照してください。

スプリントの開始/完了 (Jira Software ユーザーのみ利用可能)

Permission to start sprints and end them when the sprint dates are set. This permission doesn’t let the user change any sprint properties, such as the name, goal, and dates. The user can only change sprint status to Active or Completed.

スプリントの編集 (Jira Software ユーザーのみ使用可能)

Permission to change the sprint name and goal. With this permission, the user can’t change sprint dates nor start or end a sprint.

開発ツールの表示 (Jira Software ユーザーのみ使用可能)

Permission to view the Development panel, which provides the user with information to evaluate the status of an issue's development.

(読み取り専用) ワークフローの表示

課題を表示している際にプロジェクトの読み取り専用ワークフローを表示する権限。この権限によって、[ワークフローを表示] リンクが課題ビューの [ステータス] フィールドに表示されます。

課題の権限

説明

課題の割り当て

課題をユーザーに割り当てる権限。また、この権限は [課題の割り当て] ドロップダウンにあるユーザーのオートコンプリートを提供します。

割り当て可能なユーザー

ユーザーが課題を割り当てられる権限。ただし、これには課題を他のユーザーに割り当てる権限は含まれていないのでご注意ください。他のユーザーに課題を割り当てられるのは、課題の割り当て権限です。

課題のクローズ

ワークフロー条件に基づいて課題をクローズする権限。この権限によって、開発者は課題を解決してテスターがそれをクローズできるようになります。課題のトランジションと課題の解決権限が必要です。

課題の作成

Permission to create issues and sub-tasks (if enabled) in the project. To create attachments, the Create attachments permission is also required.

この権限を持つユーザーは、プロジェクトの閲覧権限なしで課題を作成できます。ただし、それでもユーザーが少なくともプロジェクトの閲覧権限を持っていることを確認する必要があります。そうしないと、課題を作成できても、それを見ることはできません。

課題の削除

課題を個々のコメントと添付ファイルと併せて削除する権限。

  • To delete only comments or only attachments, but not issues, users need the Delete comments or Delete attachments permissions, respectively. 
  • これらの権限のないユーザーが課題を削除すると、関連するコメントと添付ファイルも削除されます。 
  • この権限の割り当て先のグループやプロジェクト ロールは慎重にご検討ください。通常は管理者のみに付与します。 

課題の編集

課題を編集、サブタスクに変換、その逆を行う権限 (サブタスクが有効化されている場合)。

  • When granting this permission, make sure your users also have at least the Browse projects permission. Without it, they won't see any projects and issues in them.
  • Users with this permission won’t be able to edit the Due Date and Sprint fields. To allow this, give them the Schedule issues permission. 
  • The Edit issues permission is usually given to groups or project roles that have the Create issues permission. But if all your users can create issues, you may want to give the Edit issues permissions to some of them only. 
  • To delete issues, the Delete issues permission is required. 
課題のリンク

課題のリンクが有効化されている際に、課題を相互にリンクする権限。

報告者の変更

課題の報告者を修正する権限。これによって、別のユーザーの代理で課題を作成できるようになります。一般的に、この権限は管理者のみに付与する必要があります。

課題の移動

1 つのプロジェクトから別のプロジェクト、または同じプロジェクト内の 1 つのワークフローから別のワークフローへ課題を移動する権限。この権限を持つユーザーは課題の作成権限を持っているプロジェクトにのみ課題を移動できます。

課題の解決

ワークフロー条件に基づき、課題の解決および再オープンを行う権限。この権限で、課題の [修正対象バージョン] フィールドを設定することもできます。また、この権限には課題のトランジション権限が必要です。

課題のスケジュール

Permission to schedule issues by editing the Due Date and Sprint fields. In older versions of Jira, this permission also controls the permission to view the fields.

When granting this permission, make sure your users also have at least the Browse Projects permission. Without it, they won't see any projects and issues in them.

課題のセキュリティの設定

課題にアクセスできるユーザーを制御するために課題のセキュリティ レベルを設定する権限。課題セキュリティが有効になっている場合にのみ該当します。

課題のトランジション課題のステータスを変更する権限。

投票者とウォッチャーの権限

説明

ウォッチリストの管理

課題のウォッチャー リストを管理する権限。ユーザーの表示、ユーザーのリストへの追加、ユーザーのリストからの削除を行います。

投票者とウォッチャーの表示

課題の投票者リストとウォッチャー リストを表示する権限。 

コメント権限

説明

コメントの追加

課題にコメントを追加する権限。これにはコメントの編集または削除を行う権限は含まれていません。

すべてのコメントの削除

誰が追加したコメントであっても、削除する権限。

自分のコメントの削除

A user with this permission can only delete their own comments.

すべてのコメントの編集

誰が追加したコメントであっても、編集する権限。

自分のコメントの編集

A user with this permission can only edit their own comments.

添付ファイルの権限

説明

添付ファイルの作成

Permission to attach files to issues if attachments are enabled. This permission doesn't include the ability to delete attachments.

すべての添付ファイルの削除

誰が追加した添付ファイルであっても、削除する権限。

自分の添付ファイルの削除

A user with this permission can only delete their own attachments.

時間管理権限

説明

課題の作業ログ

Permission to log work on an issue (that is to create a worklog entry) if time tracking is enabled. This permission is required as a prerequisite for applying the other time-tracking permissions.

すべての作業ログの削除

Permission to delete any worklog entries, regardless of who added them. This permission only works if time tracking is enabled.

自分の作業ログの削除

A user with this permission can delete only their own worklog entries. This permission only works if time tracking is enabled.

すべての作業ログの編集

Permission to edit any worklog entries, regardless of who added them. This permission only works if time tracking is enabled.

自分の作業ログの編集

A user with this permission can edit only their own worklog entries. This permission only works if time tracking is enabled.

アーカイブ権限説明
プロジェクトの課題のアーカイブPermission to archive issues in a specific project. This permission doesn't allow the user to archive issues in bulk.
プロジェクトの課題の復元特定のプロジェクトで課題を復元する権限。
アーカイブの参照Permission to view all archived issues. To do this, go to Issues > Archived issues.
プロジェクト アーカイブの閲覧Permission to view archived issues that belong to a specific project. To do this, go to Issues > Archived issues.


権限スキーム

権限スキームのコンセプトと、このスキームを使用して Jira インスタンスでユーザーの権限を設定すべき理由についてご確認ください。 

権限スキームとは

権限スキームは、ユーザー、グループ、ロールに割り当てたプロジェクト権限をセットにしたものです。どのプロジェクトにも権限スキームがあります。1 つの権限スキームを複数のプロジェクトに関連づけることができます。

Why use permission schemes?

In many organizations, multiple projects have the same requirements for access rights. Permission schemes eliminate the need to set up permissions individually for every project. Once a permission scheme is set up it can be applied to all projects that have the same type of access requirements.

Default vs. project-specific permission scheme

All Jira instances come with the Default Permission Scheme that contains default configurations for all permissions on your instance. You can't delete the default permission scheme. 

Also, when you create a software or business project, it already has its own permission scheme assigned. The permission configurations in this project-specific scheme are very similar to those in the default permission scheme.

You can delete the permission scheme that comes with your software or business project. In this case, the default permission scheme will apply to your project. A project must always have an assigned permission scheme.

You can also create your own permission scheme and assign it to a project. The new permission scheme you assign will override the permission scheme that was previously assigned to the project. Learn how to change the permission scheme for your project

権限スキームの作成

新しい権限スキームを作成するには、次の手順に従います。 

  1. 画面右上で [管理] > [課題] の順に選択します。
  2. [権限スキーム] を選択します。使用している Jira 内のすべての権限スキームと各スキームを使用するプロジェクトのリストが表示されます。
  3. [権限スキームを追加] を選択します。
  4. [権限スキームの追加] フォームで、スキームの名前とスキームの簡単な説明を入力します。
  5. Select Add. You'll return to the Permission Schemes page where you'll find the new scheme.

権限スキームにユーザー、グループ、ロールを追加

権限スキームの権限を付与できるユーザー、グループ、ロールを追加するには、次の手順に従います。 

  1. 画面右上で [管理] > [課題] の順に選択します。
  2. [権限スキーム] を選択します。使用している Jira 内のすべての権限スキームと各スキームを使用するプロジェクトのリストが表示されます。
  3. Open a scheme by selecting Permissions in the Actions column. 
  4. ユーザー、グループ、ロールを追加する権限の [編集] を選択します。
  5. You’ll see the Grant permission dialog. Select who you want to grant the permission to. Select Grant. The selected users, groups, and roles will be added to the permission.

プロジェクト ロールは特定のチーム メンバーを各プロジェクトに定義する場合に便利です。ユーザーやグループではなくプロジェクト ロールを選択することで、システムの権限スキームの数を最小限に抑えることができます。

権限スキームからのユーザー、グループ、ロールの削除

権限スキームからユーザー、グループ、ロールを削除するには、次の手順に従います。

  1. 画面右上で [管理] > [課題] の順に選択します。
  2. [権限スキーム] を選択します。使用している Jira 内のすべての権限スキームと各スキームを使用するプロジェクトのリストが表示されます。
  3. Open a scheme by selecting Permissions in the Actions column.
  4. ユーザー、グループ、ロールを削除する権限の [削除] を選択します。
  5. 削除するユーザー、グループ、ロールを選択して、[削除] を選択します。削除されたユーザー、グループ、ロールは、権限が許可するアクションを実行できなくなります。

権限スキームとプロジェクトを関連付ける

To apply a permission scheme to a project:

  1. 画面右上で [管理] > [プロジェクト] の順に選択します。
  2. Select a project. See Defining a project for more information.
  3. [プロジェクト設定] > [権限] の順に移動します。
  4. [アクション] > [別のスキームを使用] の順に選択します。
  5. [権限スキームとプロジェクトの関連付け] ページで、プロジェクトに関連付ける権限スキームを選択します。
  6. Select Associate. The scheme will be applied to the project. 

権限スキームの削除

権限スキームを削除するには、次の手順を実行します。

  1. 画面右上で [管理] > [課題] の順に選択します。
  2. [権限スキーム] を選択します。使用している Jira 内のすべての権限スキームと各スキームを使用するプロジェクトのリストが表示されます。
  3. [アクション] 列で [削除] を選択します。既定の権限スキームは削除できないので、注意してください。
  4. [権限スキームの削除] ページで [削除] を選択してアクションを確定します。スキームが削除され、関連するすべてのプロジェクトは既定の権限スキームに自動的に関連付けられます。

権限スキームのコピー

権限スキームをコピーするには、次の手順を実行します。 

  1. 画面右上で [管理] > [課題] の順に選択します。
  2. [権限スキーム] を選択します。使用している Jira 内のすべての権限スキームと各スキームを使用するプロジェクトのリストが表示されます。
  3. [アクション] 列の [コピー] を選択します。コピー元のスキームと同じ権限を持ち、同じユーザー、グループ、ロールが割り当てられたスキームのコピーが作成されます。
最終更新日: 2022 年 12 月 6 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.