Documentation for JIRA 5.2. Documentation for other versions of JIRA is available too.

Project permissions are created within Permission Schemes, which are then assigned to specific projects.

Project permissions can be granted to:

  • 個々のユーザー
  • グループ
  • プロジェクトロール
  • Issue roles such as 'Reporter', 'Project Lead' and 'Current Assignee'
  • 'Anyone' (例: 匿名アクセスを許可する)
  • A (multi-)user picker custom field.
  • A (multi-)group picker custom field. This can either be an actual group picker custom field, or a (multi-)select-list whose values are group names.

The following table lists the different types of project permissions and the functions they secure. Note that project permissions can also be used in workflow conditions.

On this page:

プロジェクト権限

説明

プロジェクト管理

Permission to administer a project in JIRA. This includes the ability to edit project role membership, project components, project versions and some project details ('Project Name', 'URL', 'Project Lead', 'Project Description').

プロジェクトの参照

Permission to browse projects, use the Issue Navigator and view individual issues (except issues that have been restricted via Issue Security). Many other permissions are dependent on this permission, e.g. the 'Work On Issues' permission is only effective for users who also have the 'Browse Projects' permission.

View Issue Source Tab

Permission to view the related source code commits (e.g. CVS, Subversion, FishEye, etc) for an issue, in a 'Source' tab. Note that for CVS, to view the related source code commits, the project needs to be associated with at least one Repository.
Note, If you are using JIRA 5.1.1 or earlier, this permission will be named 'View Version Control'.

「読み取り専用」ワークフローの表示

Permission to view the project's 'read-only' workflow when viewing an issue. This permission provides the 'View Workflow' link against the 'Status' field of the 'View Issue' page.

課題の権限

説明

課題の割り当て

Permission to assign issues to users. (See also Assignable User permission below)

割り当て可能なユーザー

課題への割り当てが可能な権限 (注: 課題を割り当てをする権限は含みません。上記の課題の割り当てを参照ください。)

課題のクローズ

Permission to close issues. (This permission is useful where, for example, developers resolve issues and testers close them). Also see the Resolve Issues permission.

課題の作成

Permission to create issues in the project. (Note that the Create Attachments permission is required in order to create attachments.) Includes the ability to create sub-tasks (if sub-tasks are enabled).

課題の削除

課題を削除する権限。この権限を割り当てるグループやプロジェクト ロールは慎重に検討してください。通常は管理者のみに与えられます。課題を削除すると、そのユーザーがコメントの削除権限や添付ファイルの削除権限を持たない場合であっても、課題のコメントや添付ファイルがすべて削除される点にご注意ください。ただし、課題の削除権限には、個々のコメントや添付ファイルを削除する権限は含まれません。

課題の編集

Permission to edit issues (excluding the 'Due Date' field — see the Schedule Issues permission). Includes the ability to convert issues to sub-tasks and vice versa (if sub-tasks are enabled). Note that the Delete Issue permission is required in order to delete issues. The Edit Issue permission is usually given to any groups or project roles who have the Create Issue permission (perhaps the only exception to this is if you give everyone the ability to create issues — it may not be appropriate to give everyone the ability to edit too). Note that all edits are recorded in the Issue Change History for audit purposes.

課題のリンク

Permission to link issues together. (Only relevant if Issue Linking is enabled).

報告者の修正

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

課題の移動

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

課題の解決

Permission to resolve and reopen issues. This also includes the ability to set the 'Fix For version' field for issues. Also see the Close Issues permission.

課題のスケジュール

Permission to schedule an issue — that is, set and edit the 'Due Date' of an issue.

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

Permission to set the security level on an issue to control who can access the issue. Only relevant if issue security has been enabled.

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

説明

ウォッチャー一覧の管理

Permission to manage (i.e. view/add/remove users to/from) the watcher list of an issue.

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

Permission to view the voter list and watcher list of an issue. Also see the Manage Watcher List permission.

コメントの権限

説明

コメントの追加

Permission to add comments to issues. Note that this does not include the ability to edit or delete comments.

すべてのコメントの削除

Permission to delete any comments, regardless of who added them.

自身のコメントの削除

Permission to delete comments that were added by the user.

すべてのコメントの編集

Permission to edit any comments, regardless of who added them.

自身のコメントの編集

Permission to edit comments that were added by the user.

添付ファイルの権限

説明

添付ファイルの作成

Permission to attach files to an issue. (Only relevant if attachments are enabled). Note that this does not include the ability to delete attachments.

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

Permission to delete any attachments, regardless of who added them.

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

Permission to delete attachments that were added by the user.

時間管理の権限

説明

課題の作業ログ

Permission to log work against an issue, i.e. create a worklog entry. (Only relevant if Time Tracking is enabled).

すべての作業ログの削除

Permission to delete any worklog entries, regardless of who added them. (Only relevant if Time Tracking is enabled). Also see the Work On Issues permission.

自分の作業ログの削除

Permission to delete worklog entries that were added by the user. (Only relevant if Time Tracking is enabled). Also see the Work On Issues permission.

すべての作業ログの編集

Permission to edit any worklog entries, regardless of who added them. (Only relevant if Time Tracking is enabled). Also see the Work On Issues permission.

自分の作業ログの編集

Permission to edit worklog entries that were added by the user. (Only relevant if Time Tracking is enabled). Also see the Work On Issues permission.

権限スキーム

What is a Permission Scheme?

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

Why Permission Schemes?

In many organisations, multiple projects have the same needs regarding access rights. (For example, only the specified project team may be authorised to assign and work on issues).

権限スキームは、プロジェクトごとに個別にアクセス権を設定する手間を省きます。いったん権限スキームを設定すると、同じ種類のアクセス要件を持つプロジェクトすべてに、そのスキームを適用できます。

Creating a Permission Scheme

  1. Log in as a user with the 'JIRA Administrators' global permission.
  2. Choose Administration at the top right of your screen. Then choose Issues > Permission Schemes to open the 'Permission Schemes' page, which displays a list of all permission schemes in your JIRA system and the projects which use each scheme.
    (tick) Keyboard shortcut: 'g' + 'g' + start typing 'permission schemes'
  3. Click the 'Add Permission Scheme' link.
    Screenshot: The 'Permission Schemes' page
  4. In the 'Add Permission Scheme' form, enter a name for the scheme, and a short description of the scheme. Click the 'Add' button.
    Screenshot: The 'Add Permission Scheme' form
  5. You will return to the 'Permission Schemes' page which now contains the newly added scheme.
    Screenshot: the 'View Permission Schemes' page, showing the newly added scheme

Adding Users, Groups or Roles to a Permission Scheme

  1. Log in as a user with the 'JIRA Administrators' global permission.
  2. Choose Administration at the top right of your screen. Then choose Issues > Permission Schemes to open the 'Permission Schemes' page, which displays a list of all permission schemes in your JIRA system and the projects which use each scheme.
    (tick) Keyboard shortcut: 'g' + 'g' + start typing 'permission schemes'
  3. Locate the permission scheme of interest and click its name (or click the 'Permissions' link in the 'Operations' column) to show a list of permissions.
    Screenshot: Project Permissions
  4. Click the 'Add' link in the 'Operations' column, which displays the 'Add Permission' page.
  5. After selecting one or more permissions to add and who to add the selected permissions to, click the 'Add' button. The users/groups/roles will now be added to the selected permissions. Note that project roles are useful for defining specific team members for each project. Referencing project roles (rather than users or groups) in your permissions can help you minimise the number of permission schemes in your system.
    Screenshot: Add Users To Permissions
  6. 必要なユーザー、グループ、ロールがすべて権限に追加されるまで、直前の 2 ステップを繰り返します。

Deleting Users, Groups or Roles from a Permission Scheme

  1. JIRA 管理者」 グローバル権限 を持つユーザーとしてログインします
  2. Choose Administration at the top right of your screen. Then choose Issues > Permission Schemes to open the 'Permission Schemes' page, which displays a list of all permission schemes in your JIRA system and the projects which use each scheme.
    (tick) Keyboard shortcut: g + g + start typing permission schemes
  3. Locate the permission scheme of interest and click its name (or click the Permissions link in the 'Operations' column) to show the list of 'Project Permissions' (above).
  4. Click the Delete link in the "Users / Groups / Roles" column next to the name of the user, group or project role you wish to delete.

Associating a Permission Scheme with a Project

  1. JIRA 管理者」 グローバル権限 を持つユーザーとしてログインします
  2. Choose Administration at the top right of your screen. Then choose Projects > Projects to open the 'Projects' page.
    (tick) Keyboard shortcut: g + g + start typing projects
  3. Select the project of interest to open the Project Summary administration page for that project. See Defining a Project for more information.
  4. 権限セクションの右下で、現在のスキーム名(たとえば、「既定の権限スキーム」)をクリックし、プロジェクトの現在の権限スキームの詳細を表示します。
  5. アクション 」ドロップダウン メニューをクリックし、 「別のスキームの使用」を選択します。
  6. On the 'Associate Permission Scheme to Project' page, which lists all available permission schemes, select the permission scheme you want to associate with the project.
    Screenshot: The 'Associate Permission Scheme to Project' page
  7. 関連付け」ボタンをクリックし、プロジェクトを権限ボタンに関連づけます。

Deleting a Permission Scheme

  1. JIRA 管理者」 グローバル権限 を持つユーザーとしてログインします
  2. Choose Administration at the top right of your screen. Then choose Issues > Permission Schemes to open the 'Permission Schemes' page, which displays a list of all permission schemes in your JIRA system and the projects which use each scheme.
    (tick) Keyboard shortcut: g + g + start typing permission schemes
  3. 削除するスキームの削除リンク(操作列)をクリックします。
  4. 確認画面が表示されます。削除するには削除をクリックし、それ以外の場合はキャンセルをクリックします。
  5. スキームが削除され、関連するすべてのプロジェクトは既定の権限スキームに自動的に関連付けられます。(既定の権限スキームは削除できないので、注意してください。)

(info) See also Minimising the number of Permission Schemes and Notification Schemes.

Copying a Permission Scheme

  1. Log in as a user with the JIRA Administratorsglobal permission.
  2. Choose Administration at the top right of your screen. Then choose Issues > Permission Schemes to open the 'Permission Schemes' page, which displays a list of all permission schemes in your JIRA system and the projects which use each scheme.
    (tick)Keyboard shortcut: g + g + start typing permission schemes
  3. コピーするスキームのコピーリンク(操作列)をクリックします。
  4. コピー元のスキームと同じ権限を持ち、同じユーザー、グループ、ロールがその権限に割り当てられた新しいスキームが作成されます。

この表に、さまざまなグローバル権限と実行できる機能を示します。

グローバル権限

説明

JIRA システム管理者

Permission to perform all JIRA administration functions.
(warning) This does not include the JIRA Users permission. A user with JIRA System Administrators will be able to log in to JIRA without the JIRA Users permission, but may not be able to perform all regular user functions (e.g. edit their profile) unless they also belong to a group that has the JIRA Users permission.

JIRA 管理者

Permission to perform most JIRA administration functions (see list of exclusions below).
(warning) This does not include the JIRA Users permission. A user with JIRA Administrators will be able to log in to JIRA without the JIRA Users permission, but may not be able to perform all regular user functions (e.g. edit their profile) unless they also belong to a group that has the JIRA Users permission.

JIRA Users

Permission to log in to JIRA.
(warning)  The number of users that count towards your JIRA license is the sum of all users (including users in groups) that have this permission. If you want to reduce this count, see How do I reduce my user count in JIRA.
(info) Granting the JIRA Users permission to a group results in all newly created users being automatically added to that group. The exception to this are groups that also have either the JIRA System Administrators or JIRA Administrators permissions, since JIRA prevents groups with these administrative-level global permissions from being granted the JIRA Users permission. Furthermore, it would be unwise to automatically grant these administrative-level global permissions to all new users.

ユーザーの参照

Permission to view a list of all JIRA user names and group names. Used for selecting users/groups in popup screens (such as the 'User Picker'). Enables auto-completion of user names in the 'User Picker' popup screen.

共有オブジェクトの作成

Permission to share a filter or dashboard globally or with groups of users.

グループフィルターサブスクリプションの管理

グループフィルターサブスクリプションを管理 (作成、削除) する権限。

一括変更

Permission to execute the bulk operations within JIRA:
- Bulk Edit *
- Bulk Move *
- Bulk Workflow Transition
- Bulk Delete *
( * subject to project-specific permissions.)

(warning) The decision to grant the Bulk Change permission should be considered carefully. This permission grants users the ability to modify a collection of issues at once. For example, in JIRA installations configured to run in Public mode (i.e. anybody can sign up and create issues), a user with the Bulk Change global permission and the Add Comments project permission could comment on all accessible issues. Undoing such modifications may not be possible through the JIRA application interface and may require changes made directly against the database (which is not recommended).

2 Comments

  1. Jacques

    The logic of this page would make so much more sense if the paragraphs "What is a Permission Scheme?" and "Why Permission Schemes?" were at the top of the page, followed by the different project permissions and then how to create/assign permission schemes.

    (smile)

    1. SusanA

      Hello Jacques, I just looked at this page and I have to say that I agree with you. I haven't been here long, but I will look into reorganizing this for the next JIRA release. Thanks for your feedback.