Creates a new permission scheme. You can create a permission scheme with or without defining a set of permission grants. Permissions required:Administer Jiraglobal permission.
Returns all permission schemes. ### About permission schemes and grants ### A permission scheme is a collection of permission grants. A permission grant consists of a holder and a permission. #### Holder object #### The holder object contains information about the user or group being granted the permission. For example, the Administer projects permission is granted to a group named Teams in space administrators. In this case, the type is \"type\": \"group\", and the parameter is the group name, \"parameter\": \"Teams in space administrators\". The holder object is defined by the following properties: * type Identifies the user or group (see the list of types below). * parameter The value of this property depends on the type. For example, if the type is a group, then you need to specify the group name. The following types are available. The expected values for the parameter are given in parenthesis (some types may not have a parameter): * anyone Grant for anonymous users. * applicationRole Grant for users with access to the specified application (application name). See Update product access settings for more information. * assignee Grant for the user currently assigned to an issue. * group Grant for the specified group (group name). * groupCustomField Grant for a user in the group selected in the specified custom field (custom field ID). * projectLead Grant for a project lead. * projectRole Grant for the specified project role (project role ID). * reporter Grant for the user who reported the issue. * sd.customer.portal.only Jira Service Desk only. Grants customers permission to access the customer portal but not Jira. See Customizing Jira Service Desk permissions for more information. * user Grant for the specified user (user ID - historically this was the userkey but that is deprecated and the account ID should be used). * userCustomField Grant for a user selected in the specified custom field (custom field ID). #### Built-in permissions #### The built-in Jira permissions are listed below. Apps can also define custom permissions. See the project permission and global permission module documentation for more information. Project permissions * ADMINISTER_PROJECTS * BROWSE_PROJECTS * MANAGE_SPRINTS_PERMISSION (Jira Software only) * SERVICEDESK_AGENT (Jira Service Desk only) * VIEW_DEV_TOOLS (Jira Software only) * VIEW_READONLY_WORKFLOWIssue permissions * ASSIGNABLE_USER * ASSIGN_ISSUES * CLOSE_ISSUES * CREATE_ISSUES * DELETE_ISSUES * EDIT_ISSUES * LINK_ISSUES * MODIFY_REPORTER * MOVE_ISSUES * RESOLVE_ISSUES * SCHEDULE_ISSUES * SET_ISSUE_SECURITY * TRANSITION_ISSUESVoters and watchers permissions * MANAGE_WATCHERS * VIEW_VOTERS_AND_WATCHERSComments permissions * ADD_COMMENTS * DELETE_ALL_COMMENTS * DELETE_OWN_COMMENTS * EDIT_ALL_COMMENTS * EDIT_OWN_COMMENTSAttachments permissions * CREATE_ATTACHMENTS * DELETE_ALL_ATTACHMENTS * DELETE_OWN_ATTACHMENTSTime tracking permissions * DELETE_ALL_WORKLOGS * DELETE_OWN_WORKLOGS * EDIT_ALL_WORKLOGS * EDIT_OWN_WORKLOGS * WORK_ON_ISSUESPermissions required: Permission to access Jira.
Updates a permission scheme. Below are some important things to note when using this resource: * If a permissions list is present in the request, then it is set in the permission scheme, overwriting all existing grants. * If you want to update only the name and description, then do not send a permissions list in the request. * Sending an empty list will remove all permission grants from the permission scheme. If you want to add or delete a permission grant instead of updating the whole list, see Create permission grant or Delete permission scheme entity. See About permission schemes and grants for more details. Permissions required:Administer Jiraglobal permission.