Administering a Jira instance is a kind of art. Creating naming conventions, using your favorite apps to automate manual steps, setting up project roles in combination with permissions, and so on. Still, when 2 artists work together, their life can turn out to be quite tough. Suddenly you realize that changes have been made in the instance configuration you are not aware of.
In this scenario, you are an experienced Jira administrator at BigTech LLC, who is working together with another expert, Jason. Some of the projects within the Jira instance have been created and configured by Jason alone and you haven't dealt with those projects before.
In Jason's absence, some new requests have been submitted to you, regarding his projects. You know you are skilled to carry out the necessary changes but the task would be much easier if you had previous experience with these projects. Luckily, BigTech is an enlightened company that cares about its workers and purchased Glass Project Documentation for their Jira instance. Also, they granted the View Glass Documentation permission to all logged-in users, so every project you can access has an extension called Glass Documentation, which will help you understand the basics of Jira, and unveil the details of the project configuration.
First of all, using Glas, you can quickly assess the complexity of the project. Right after, you will be able to give a fair estimation of the real complexity of the requests. Then you will have to investigate a couple of permission-related issues and find the proper solution for them. There is also a specific request about a custom post function, we'll look into that soon. In the end, you will have to prepare for an internal audit and export the project documentation into PDF and Confluence.
Problem: You need to make changes in the configuration of a project you have not dealt with before.
How to solve it in theory: Open Glass Dashboard and check the available schemes and stats.
Steps to carry out: Open Glass Documentation from the project sidebar.
Login details are as follows:
In the Glass Overview area, have a look at
Based on the above details you can see that the project was probably created recently and the configuration is rather simple at the moment. Only a few workflows have been added and just a few people are involved. Let's also have a look at the Schemes.
Note that in the on-premise version of Glass, the number highlighted in grey shows the occurrence of the selected scheme ie. across how many projects the particular scheme is being used. In our case, the BIGTECH: Issue Type Scheme is used only in the Bigtech project, so changes made to this scheme will not affect other projects.
Problem: There is a workflow associated with the Bigtech project; you have to make sure that resolutions will be set properly across the workflow.
How to solve in theory: Open the corresponding issue type on the Issue Type tab and investigate custom workflow actions.
Steps: Open the Issue Types tab and select the Story issue type and look at the associated workflow. In general, the resolution of an issue should be set, when a transiton leads to a "Done" type status (such as Canceled or Closed) and usually should be cleared when the issue is transitioned back to a "To do" or "In Progress" type status. Click on a particular transition to review its workflow post functions.
Let's have a look at the corresponding transitions and check whether the resolution value is properly set.
The Canceled global transition seems right:
The Resolved reused transition is a bit tricky, here the resolution should be set on the "Resolve issue" transition screen:
As to the Reopen transition, the Resolution is cleared as expected.
Numbers highlighted in blue color mark custom workflow actions, feel free to have a look at those as well:
Problem: John Doe reported that although he seems to have access to the Bigtech project, he is unable to create new issues in it.
How to solve in theory: Open the Permissions and People tabs in Glass and investigate the configuration details.
Steps: First, let's examine the project permissions. Check to whom the Browse Project and the Create Issues permissions are granted.
As per the scheme, only Administrators are allowed to create issues in this project.
Let's now open the People tab and see the members of the Administrators project role. As you can see, there is only one person (Balázs) and a user group (jira-administrators) in the role. Click on the jira-administrators group and search for John.
John seems to be right, he is not a member of the Administrators project role, therefore he cannot create issues in the Bigtech project.
You have multiple options to solve this issue:
You also might want to know, what else members of the Administrators project role are allowed to do in the project. Let's open the Permissions tab once again, and select View by Actors to see all project permissions assigned to the Administrators role.
Problem: It's time for an internal audit, the Bigtech project must be documented beforehand.
How to solve in theory: Open Glass Documentation, and create a PDF or Confluence export.
Steps to carry out: Open Glass, click on "Export as" and select PDF. The export shouldn't take longer than a few seconds. The automatically created documentation contains all the information that's available in Glass, including a cover page and the details of every workflow available in the project. In the case of the Bigtech project the export is about 47 pages long. You just saved 40 valuable working hours!
If version control is of importance to your organization, you might want to consider exporting to Confluence where version control is possible by relying on the native versioning capabilities of Confluence.
The contents of the Confluence export are pretty much the same as in case of the PDF export:
This is it for now. Let's have a nap before the audit starts!
Administering a Jira instance is a kind of art. Creating naming conventions, using your favorite apps to automate manual steps, setting up project roles in combination with permissions, and so on. Still, when 2 artists work together, their life can turn out to be quite tough. Suddenly you realize that changes have been made in the instance configuration you are not aware of.
In this scenario, you are an experienced Jira administrator at BigTech LLC, who is working together with another expert, Jason. Some of the projects within the Jira instance have been created and configured by Jason alone and you haven't dealt with those projects before.
In Jason's absence, some new requests have been submitted to you, regarding his projects. You know you are skilled to carry out the necessary changes but the task would be much easier if you had previous experience with these projects. Luckily, BigTech is an enlightened company that cares about its workers and purchased Glass Project Documentation for their Jira instance. Also, they granted the View Glass Documentation permission to all logged-in users, so every project you can access has an extension called Glass Documentation, which will help you understand the basics of Jira, and unveil the details of the project configuration.
First of all, using Glas, you can quickly assess the complexity of the project. Right after, you will be able to give a fair estimation of the real complexity of the requests. Then you will have to investigate a couple of permission-related issues and find the proper solution for them. There is also a specific request about a custom post function, we'll look into that soon. In the end, you will have to prepare for an internal audit and export the project documentation into PDF and Confluence.
Problem: You need to make changes in the configuration of a project you have not dealt with before.
How to solve it in theory: Open Glass Dashboard and check the available schemes and stats.
Steps to carry out: Open Glass Documentation from the project sidebar.
Login details are as follows:
In the Glass Overview area, have a look at
Based on the above details you can see that the project was probably created recently and the configuration is rather simple at the moment. Only a few workflows have been added and just a few people are involved. Let's also have a look at the Schemes.
Note that in the on-premise version of Glass, the number highlighted in grey shows the occurrence of the selected scheme ie. across how many projects the particular scheme is being used. In our case, the BIGTECH: Issue Type Scheme is used only in the Bigtech project, so changes made to this scheme will not affect other projects.
Problem: There is a workflow associated with the Bigtech project; you have to make sure that resolutions will be set properly across the workflow.
How to solve in theory: Open the corresponding issue type on the Issue Type tab and investigate custom workflow actions.
Steps: Open the Issue Types tab and select the Story issue type and look at the associated workflow. In general, the resolution of an issue should be set, when a transiton leads to a "Done" type status (such as Canceled or Closed) and usually should be cleared when the issue is transitioned back to a "To do" or "In Progress" type status. Click on a particular transition to review its workflow post functions.
Let's have a look at the corresponding transitions and check whether the resolution value is properly set.
The Canceled global transition seems right:
The Resolved reused transition is a bit tricky, here the resolution should be set on the "Resolve issue" transition screen:
As to the Reopen transition, the Resolution is cleared as expected.
Numbers highlighted in blue color mark custom workflow actions, feel free to have a look at those as well:
Problem: John Doe reported that although he seems to have access to the Bigtech project, he is unable to create new issues in it.
How to solve in theory: Open the Permissions and People tabs in Glass and investigate the configuration details.
Steps: First, let's examine the project permissions. Check to whom the Browse Project and the Create Issues permissions are granted.
As per the scheme, only Administrators are allowed to create issues in this project.
Let's now open the People tab and see the members of the Administrators project role. As you can see, there is only one person (Balázs) and a user group (jira-administrators) in the role. Click on the jira-administrators group and search for John.
John seems to be right, he is not a member of the Administrators project role, therefore he cannot create issues in the Bigtech project.
You have multiple options to solve this issue:
You also might want to know, what else members of the Administrators project role are allowed to do in the project. Let's open the Permissions tab once again, and select View by Actors to see all project permissions assigned to the Administrators role.
Problem: It's time for an internal audit, the Bigtech project must be documented beforehand.
How to solve in theory: Open Glass Documentation, and create a PDF or Confluence export.
Steps to carry out: Open Glass, click on "Export as" and select PDF. The export shouldn't take longer than a few seconds. The automatically created documentation contains all the information that's available in Glass, including a cover page and the details of every workflow available in the project. In the case of the Bigtech project the export is about 47 pages long. You just saved 40 valuable working hours!
If version control is of importance to your organization, you might want to consider exporting to Confluence where version control is possible by relying on the native versioning capabilities of Confluence.
The contents of the Confluence export are pretty much the same as in case of the PDF export:
This is it for now. Let's have a nap before the audit starts!