Atlassian Jira Administrator ACP-100 – Introduction and the Jira Atmosphere Part 5

18. How to Test, Share, and Troubleshoot Workflows

Workflows are essential in Jira. In addition to building workflows, you need to test those workflows to make sure they work correctly. And you may want to import and export workflows in and out of your Jira instance for several reasons. Let’s take a look at all three of these tasks as they apply to a Jira administrator. Testing workflows is an important task as a Jira admin, and there are a few strategies available to you. Test in a test environment if your workflow contains a complex script with automation, and you want to evaluate if the script and workflow consume too many resources before building in your production environment, use a test project.

Most often, you can test your workflow in a test project before adding the workflow to real projects. If something doesn’t work, you don’t want to risk upsetting the daily work of your users. In an active project, workthrough workflows in all applicable roles. This process allows you to make sure all statuses transitions and functions work properly. If you have an approval, for example, you definitely want to check that it works. The same goes for post functions that carry out additional actions for specific users.

Test as every involved user to make sure you get their experience correct. So how do you test build a workflow, then run through all transitions and statuses? How do you test workflows at your organization? Do you have a testing or staging environment to work with? Now let’s talk about importing and exporting workflows as an option in your Jira instance.

There are a couple of options available for import and export XML and workflow. When you export as XML, you receive an XML file of the Jira workflow. Originally, this option was helpful for those who wanted to edit XML files in a text editor prior to the visual editor that became available. In later versions of Jira. You might also find the XML export useful as a backup and for importing into another Jira instance. However, be aware that workflow functions in one system may not be available in the target system, and you may have to rebuild those such as validators or post functions. When you export as a workflow, you have the option to add notes to help the importer understand additional configuration for the workflow. Exporting a workflow as a workflow is the choice for sharing on the marketplace. You can also use this option if you want to import the workflow into a different Jira instance.

Note that if you use third party app functionality in your workflow, such as a Script Runner scripted condition, that condition does not export, but information on the plugin shows up in the export notes. If you export a workflow to share on the Atlassian marketplace, make sure to include configuration needs in the Add Notes field. When you use an app such as Script Runner for Jira, the app may put information n the add notes field automatically. Once you export a workflow or if you choose to use a workflow from another source, you need to import that workflow.

As with workflow exports, there’s an XML option and a Workflow option. If you import as XML, you have two choices. The first is just to provide the file path to the server that the XML file is stored on. The second option is to copy and paste the XML definition from the downloaded file. For this option, use a text editor to open the XML definition and then paste it in the Workflow definition. XML Field When you import an XML workflow, there’s no importer tool for mapping. As with other new workflows, you need to review the workflow after import and associate with a workflow scheme to make it active. If you import as a workflow, you can search the marketplace or load a saved file. You provide a name for the new workflow and then map statuses in the target instance.

This option allows you to modify the new workflow in the importer by updating statuses if the imported workflow includes screens or references. Custom fields, those screens and fields are added to the target instance. However, if you import a workflow with a screen or custom field you already have available on your instance, you get a duplicate screen and field. This particular issue is currently being tracked by Atlassian. Also with this option, if the exported workflow includes notes from the addnotes field, you can see them as part of the importer and take action based on those notes. If you disable any custom fields on a workflow and export that workflow, the workflow importer doesn’t create these custom fields to allow the importer to create these fields. Enable the custom fields before importing so that’s importing and exporting workflows in Jira now let’s talk about troubleshooting.

When it comes to technology, sometimes things just don’t go as we expect. Workflows in Jira are no different to troubleshoot workflows. Start with understanding what action should take place when something fails, and then try to diagnose the root cause. Once you know what should happen with a particular action, then you can navigate to the workflow area where the error occurs, looking at the workflow functions such as a validator, and then reviewing the configuration. From there, you can review any Java errors such as this one, which indicates that a plugin or condition uses is uninstalled. Another step in workflow troubleshooting is to view the Atlassian Jira log the main Jira log, to see if you can get any additional clues to the workflow error. We COVID support tools and reviewing the Jira logs in another video. And for more information on troubleshooting, check out the Jira Administrator reference guide.

19. How to Manage Users

Jira provides different ways for users to authenticate as well as store their user information, such as username email address and password. Let’s talk about what a Jira user is and about the options for user management in Jira. In Jira, a user is any person with an account in the system. You grant users access to Jira applications as well as permissions to work in projects. There are a few ways to add users you can create directly in Jira using the Jira internal directory, and this directory stores all user and group information inside the Jira database and can support the use of nested groups. If you enable this option, you can use another instance, and this option uses the Atlassian Jira directory. We talk more about this process in the reference guide. Or you can use an external directory tool such as Microsoft Active Directory. This option is useful for organizations already using an external directory for other applications. When you use this option, you can use local groups from the Jira database if you choose, meaning user information is only ready when a user logs in.

This option also auto populates a user’s group membership when they log in. For more in depth information about user management options and the use of external directories, check out the Jira Administrator Reference Guide. You may need to create users for a variety of reasons, including creating test or temporary accounts. When you create a user manually, you need to include an email address, a full name, a username which should not be the same as the email address, a password, and the selected application the user needs access to.

And note that manually creating a user is the only way to set a password for that user. Inside of Jira, we’re going to do a quick walkthrough of creating a user manually. We’ll create a new test account, and we enter the details for the test user, including a password. To create the test user, we then just click Create User. Note that when you create a user manually, you can send a notification email to let the user know about their new account. This option is not the same as inviting through email, which we talk about next. In addition to manually creating users, you can invite a user through email.

This option allows you to send invites to a set of users by adding their email addresses and then selecting the appropriate application access. If the user accepts the invite, they receive access to the selected application and get a Jira account. If they don’t accept the invite, it expires, and your user license count isn’t affected. Each invitation only works with the email it was sent to, and you can use that invitation once. So if a user doesn’t accept, you need to send a new invitation, and these invites expire after seven days. Can you think of some situations in your own organization where you might invite users versus creating them?

Consider your end goal when it comes to creating a user, either through Jira or through an external tool, or inviting a user. Because invitations are onetime use and don’t use up a license until the user accepts, they may be useful when setting up Jira access for a group whose needs are uncertain. For example, perhaps you have a team that wants to evaluate Jira, and you aren’t sure all of the team need access right away. Be aware that when you use multiple user directories, jira checks those directories from top to bottom. When a user authenticates, you can change this order using the arrow buttons in the order column. It’s also important to note that the first user account found in a directory is the one that Jira will use. For example, if V burton had an account in both the internal Jira directory and the LDAP directory with two different passwords, one for each account.

The password associated with the internal Jira directory is what she needs to use to log into Jira, as that directory is listed first in the user directories of the instance. If needed, you can migrate users between two user directories. You may want to use this option if you need to condense user directories for whatever reason, such as moving internal users to a delegated LDAP directory. We talk more about this option in the Jira administrator reference guide. Violet needs to create a few temporary accounts for the Great Adventure Jira instance. She wants things to be consistent and make sense so there aren’t any errors or misinformation in the system. She makes sure that Great Adventure uses a username convention for her instance. It’s the final initial of the user’s first name and then the user’s last name, such as V burton or l sloan.

She also makes sure that no one uses the email as the username in the system and ensures there are no duplicate usernames. Along with keeping these other best practices in mind, store users and groups centrally. Use a third party directory service such as LDAP or Active Directory for enterprise instances to backup user accounts and so that users can use the same credentials for all other applications in the organization. Even if you do use an external directory, make sure to keep a local Jira system administrator account in the Jira internal directory.

You want to make sure someone still has access to Jira in case the external directory can’t connect to the Jira instance, use a single sign on service such as Crowd if you use several Atlassian applications, this option helps users log in once and have access to all the Atlassian applications inside your organization. Finally, avoid duplicate usernames between directories. Ensure any usernames in multiple user directories offer the same person. If you change the user directory order and you have two users with the same username, one user may not be able to log in after a directory order change.

20. How to Manage Global Permissions and Create a System Administrator Group

Global permissions are the overarching set of permissions that apply to all users and projects inside of Jira and include administration permissions as well as global functions such as creating Dashboards. Jira has six global permissions, two of which are administrative permissions. You map global permissions to groups, and you can’t further edit these permissions. They are not granular. These global permissions work on the instance level and determine what user can do in Jira as a whole, such as creating their own Dashboards or a filter subscription. The four non administrator global permissions include Browse Users, which controls who can view lists of users and groups inside of Jira as well as share issues and mention users on issues. Review this permission if you have a public Jira instance in case you don’t want all users to see all other users. Create shared Objects, which controls who can create filters, dashboards, and software boards and share them with other users.

Manage Group Filter Subscriptions, which controls who can create, modify, or delete group filter subscriptions bulk Change, which controls who can modify issues using bulk change, including editing, moving, transitioning, or deleting issues. We recommend awareness of the way global permissions work with project permissions so you ensure both sets of permissions are secure. You don’t want users to cause data loss or corruption. For example, users with a bulk change global permission and the Delete Issues project permission could easily delete all of the issues in a project. By default, Jira grants each application group all four no administrative global permissions. For example, all Jira software users can create their own software boards and use bulk change. Consider these defaults when adding users to these groups or any other groups you grant these permissions to.

As mentioned, some global permissions could cause problems in projects, and we recommend restricting some global permissions to certain groups. Of the four permissions, bulk change and manage group filter subscription are the two you should scrutinize most, ensuring that the appropriate users have these permissions. Bulk change paired with the right project permission could result in a mass transition or deletion of issues. Manage group filter subscription could result in a user effectively spamming other users with a filter subscription if those settings are too frequent. Violet plans to review these permissions with other staff members to see what groups really need. Which global permissions do you need to adjust any default global permissions in your instance? In addition to the non administrator global permissions, there are two administrator permissions.

The Jira system administrator splits any function that could result in a loss of data or configuration change and affect the system side of the instance. This global permission allows you to have a small set of users responsible for the core Jira functionality and avoid giving too many users too much administrator access in Jira. Additionally, the Jira administrator global permission focuses on tasks such as creating and managing users, indexing the instance, and modifying the allowed attachment size for a full table of Jira System Administrator capabilities. Check out the Jer administrator reference guide. In addition to separating the Jira Administrator and Jira System Administrator permissions in your instance, we also recommend that you don’t give regular Jira Administrators access to Jira’s file, system or database. Keep that access as system administrator only. Violet needs to split these permissions. She plans to add a few Jira Administrators to the team, but she doesn’t want them to have all the keys to the castle. To restrict access, Violet needs to create a System Administrator group and set herself as a first member of that group. Let’s see how she does it.

Navigate to the group’s page. On the Groups page, in the Name field, tape a name for your new group. Violet needs to create the Jira System Administrators group. Click add group. To add the group to your instance, you should see the Jira System Administrators group. Click Edit Members to add members to this group. On the edit members page under Add members to select groups. Search for it and select a user to add. Right now, Violet needs to add herself as a member of this group. Click Add Selected Users to add the users to the group.

Next, you need to adjust the global permissions of your instance to update the group granted the System Administration global permission. Navigate to the global permissions page. On the Global Permissions page, scroll to the Add Permissions section at the bottom of the page. From the permission menu. Select Jira System administrators. From the Group menu, select the group you created for this permission, and then click Add. We need to use the Jira System Administrators group. Now scroll back up and delete the Jira Administrators group from the Jira System Administrators permission to remove this group’s access to System administrator functions in Jira. On the following page, click Delete again to confirm the removal of this group.