Exam Topic:
Important Notes:
- Determine the appropriate use of application access, groups, roles and permissions.
- Identify and troubleshoot user settings, user profiles and permissions. Given a scenario, recommend the appropriate configuration of user and project permissions, roles and group membership.
- Given a scenario, determine the impact of deleting/deactivating a user/group.
- Determine if and how issue-level security should be configured in a project.
- Application Access
- To login to jira, user must have application access (Jira license)
- To browse projects, users must browse project access in permissions schemes assigned to projects.
- To browse Users, group of users should have Browse Users in Global Permissions.
- People who have the JIRA Administrators permission (and not the JIRA System Administrators permission) cannot do the following:
- Configure JIRA's SMTP mail server for notifications (but they can enable/disable SMTP mail server and configure POP/IMAP mail servers for the receipt of email messages that create issue comments and new issues, and fully administer email notification schemes).
- Configure listeners.
- Configure services (except for POP/IMAP services).
- Change the index path (but they can reindex and optimise the index).
- Run the integrity checker.
- Access logging and profiling information.
- Access the scheduler.
- Export/backup JIRA data to XML.
- Import/restore JIRA data from XML.
- Import XML workflows into JIRA.
- Configure attachments (but they can set the size limits of attachments and enable thumbnails).
- Add gadgets to the Gadget Directory.
- Configure user directories (e.g. LDAP).
- Configure Application Links that use an authentication type other than OAuth.
- View user sessions.
- Access license details.
- Grant/revoke the JIRA System Administrators global permission.
- Edit (or Bulk Edit) groups that have the JIRA System Administrators global permission.
- Edit, change the password of or delete a user who has the JIRA System Administrators global permission.
- Upload and/or install an Add-on (But Can Request).
- It is recommended that people who have the JIRA Administrators permission (and not the JIRA System Administrators permission) are not given direct access to the JIRA file system or database.
- Global Permissions
- Jira System Administrators : Ability to perform all administration functions. There must be at least one group with this permission.
- Jira Administrators: Ability to perform most administration functions (excluding Import & Export, SMTP Configuration, etc.).
- Browse Users: Ability to select a user or group from a popup window as well as the ability to use the 'share' issues feature. Users with this permission will also be able to see names of all users and groups in the system.
- Create Shared Objects: Ability to share dashboards and filters with other users, groups and roles.
- Manage Group Filter Subscriptions:Ability to manage (create and delete) group filter subscriptions.
- Bulk Change: Ability to modify a collection of issues at once. For example, resolve multiple issues in one step.
- Project Level Permissions
- All project level permissions work as
- Permissions schemes are defined with all project level permissions like browse project, create issue, delete issue etc..
- In permission schemes permissions can be assigned
- Permission schemes are assigned at following levels
- Project Role
- Application access
- Group
- Reporter
- Single user
- Project lead
- Current assignee
- Group custom field value
- Permissions schemes are assigned to projects
- Best practices for permissions is create project roles and manage permissions at project role level.
- Exam scenarios troubleshooting tips
- Following are possible permissions issues.
- Application Access
- Global Permissions.
- Project level permission from permission scheme
- Workflow conditions
- Workflow properties
- Issue security
- While answering the question , read the scenario and ask questions to yourself
- Why the user having the problem
- What they can access
- What they cannot access
- Identify, what is level of the problem
- Project level
- Issue level
- Application level
- Workflow action/transition
- Common troubleshooting scenarios
- Scenario1:
- Issue: A user can access one project in jira but not in other
- Possible Resolution: User does not have browse project permission for one project
- Scenario2
- Issue: User can perform one workflow action but not on other
- Possible Resolution: There might be workflow conditions applied or status properties
- Where we can use groups and project roles
- Groups can be used in
- Permission Schemes
- Notification schemes
- Issue security schemes
- Workflow conditions
- Filters & Dashboards sharing
- Project-Roles
- Filters subscriptions
- In following areas only groups can be used
- Application Access
- Global Permissions
- Project Roles can be used in
- permission schemes
- email notification schemes
- issue security levels
- comment visibility
- workflow conditions
- issue filters
- Filters & Dashboards sharing
- Project roles are preferred on groups
- Scenario:
- If you have asked to judge to create new role or to use the existing one
- Whenever possible reuse the existing role instead of adding new one
- When to use what
- Issue security
- To hide specific issues from specific people.
- Project Permission
- Any thing related to project like create issue, edit issue, view all issues, create comment
- Workflow conditions
- Block a transition and transition will not appear at all if condition passed
- Workflow Validations
- To validate mandatory fields
- Transition can be seen but to validate a condition while executing the transition
- Workflow Properties
- Block issue edit on a specific status
- User Deletion &De -Activation
- Deactivating a user is preferred rather than deleting the user, because deleting a user can create issues in jira for example, filters and search will not work properly
- Deleting a user can impact on following areas if used (Create, edit, or remove a user)
- Filters where user is referred
- Workflow configurations
- Deleting a group can impact if its used somewhere, it's better to verify if groups is used somewhere before deleting (Create, edit, or remove a user)
- Issue Security
- Helps to determine which user or group of users can view the issue and common scenarios where it can be used are
- Only a special group can view a few issues.
- Only creator or assignee can view the issues
- Jira admin has to create the issue security scheme and link with the project. There is no default issues security schemes comes with jira
- Set issue security permission in permission scheme allows who can set the issue security
- Security level can be set at issue create or in workflow post function
- Issue security levels can be defined on
- Application access
- Any logged in user
- Jira software users
- Reporter
- Group
- Single user
- Project lead
- Current assignee
- User custom field value
- Project Role
- Group custom field value
Please feel free to provide your feedback in comments section. I would be happy to answer all of your queries
About Author
Muhammad Ramzan is a certified Atlassian Consultant having 10+ years of professional experience in the area of DevOps, Software Testing(Manual/Automation) and Atlassian Tools Administration
0 Comments