Preparing ACP-600 Project Administration in Jira Server: Part II Labs

Let’s talk about the 24 hours lab that Atlassian provides when you buy the ACP-600 preparation course + exam bundle.

The preparation course is highly recommended and there is enough material to pass the exam. In addition, the exman only costs the same as buying the course + exam bundle.

As for the laboratory in particular. At the moment of activating it, you have 24 hours of access to it. The access is not automatically activated when buying the course, so you can organize yourself and activate the lab when you have more free time.

In my case, I spent about 8 hours with the lab, including documenting everything I was doing + some breaks in between. A pdf is already provided with all the steps detailed, though.

It is quite simple but if you want to consider it seriously, I recommend dedicating about 7-8h (maybe a Saturday at home?).

The exercises are well documented in the pdf and it is made in a way that you can try yourself before jumping to the next page and reading the solution.

I am not going to copy & paste anything from the PDF, as I would like to avoid any copyright violation, but I am going to document everything I have learned that I think is important, as short questions and answers. If you want to dive deep into any of the points, I recommend reading the official documentation.

Project Administration in Jira Server Lab: Questions and Answers

Permissions

When do we need a Jira Administrator? We need one when we need for example to create/edit…

• New issue type
• New screen
• New workflow for some issue types, eg. we need a new workflow for Task and Bug issue types.
• To remove a workflow condition
• New field in some issue types
• Edit permission scheme
• Edit Issue security scheme
• Edit priorities
• Edit Notification scheme
• New resolutions
• New Issue link types
• Edit the Field configuration: hidden, required, render, description
• Edit Screen schemes or issue type screen schemes
• Edit global permsissions: bulk, shared object, browse user, group filter subscription
• Transition screen
• Transition elements: triggers, conditions, validators, and post functions (A project admin can reuse a transition and its elements if they already exist)
• Restrict transition to a group/role
• Status properties
• Custom fields: A Jira Administrator can set the context, where the field can be used (issue types)

Examples:

• A Jira Administrator can create a condition to prevent specific groups/users from moving issues

And what can we do as Project Administrators? Here some examples:

• Create versions
• Edit screens
• Remove transition in workflow
• Remove statuses from workflow: If no issue is in that status. Don’t forget to remove its column on the Jira board, in case the project has one.
• Reuse transitions: if has the same destination status. The transition elements will be reused as well (conditions, validators, etc.)
• Delete issues
• Modify reporter
• Manage watch
• Manage comments (require more permissions)
• Manage worklogs (requires more permissions)

Use cases

• Can’t move an issue to a specific status? Check if there is a transition to that status
• Can’t users see the transition? A Condition might exist for that transition preventing the specific user of using it
• Can’t edit fields on a screen? The screen might be being shared by other projects

• Can’t see security level field? Enable Security level for the project

• Users can “Configure Fields”: fields they want to see on screens

• Can’t users hide the Summary field in “Configure fields”? Summary is a required field

• Browse Projects permission? View project and its issues, use issue navigation

• Permission scheme: add individual users? It’s not best practice. Better add roles (requires Jira Administrator perms)

• Permission scheme has no global permissions (as share objects)

• Merge versions? The old version will be removed and issues will be updated

• Default Assignee? Can be: Component lead, unassigned, project default, project lead

• Global transitions = statuses are able 2 transition 2 all
• Add status (column) using board? It will be global transition

• Add status (column) using board? If simplified workflow

• Edit workflow? The project cannot be shared or be a system workflow. It requires to have extended permisssions
• Extended Project Administration permission is enabled by default when using templates

Charts & Dashboards

• Created vs Resolved Issues Report: backlog growing or shrinking
• Time Report: length of time to resolve issues for a project or filter
• user with most issues assigned? Use pie chart
• where project issues are in the workflow? Pie chart: status
• Single level group by report: Shows issues grouped by field

• Team members can run reports

• Edit dashboard? only owner or jira administrator

• Default board administrator? Project lead when the project is created
• Default board column names = workflow status names