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

12. How to Create Issue Security Schemes

Issue security schemes allow you to specify security restrictions on individual issues with custom security levels. Security levels specify if a user group or members of a project role can see an issue. Without the security level clearance, a user cannot see the issue. You set security level by selecting from a dropdown field or by automation during an issue transition. Issue level security restricts individual issues and is typically used for high security issues in a project. Some situations where you might use issue level security include you need to keep an issue private due to its personal nature, such as an HR development plan. You need to keep an issue restricted to admins. You need to keep an issue hidden for client privacy. You don’t use issue level security.

One, you need to set privacy for groups of issues. In this case, you can use a separate project. You need to set access for certain roles to create or edit issues. In this case, you handle through permissions. So that’s issue security in a nutshell. Let’s talk about how those work in schemes. Issue security schemes let you apply security levels to projects. As with other schemes in Jira, you can share these schemes with an issue security scheme. You set the levels of issue security. You can create the name of the level and the user group or role the level applies to as part of this process.

Don’t forget to set the reporter so they can still see the issue after they create it. When you select who to assign to a security level, don’t use an individual user. If you can help it, use groups or roles instead so you can avoid orphaned issues. Once you have an orphaned issue, no one will be able to see the issue. To update the security level, Violet has requests from the Finance and HR teams to put an issue security scheme in for their sensitive issues. Finance has payroll issues that should only be seen by managers, and HR has issues that should also only be seen by managers and administrators. She plans to create a manager restricted issue security scheme to use in these specific projects.

Navigate to the issue. Security scheme page. On the Issue security Scheme page, click add. Issue security scheme. On the next page, add a name and a description for your scheme, and click Add. Violet calls scheme manager restricted. She sets the description as this scheme should be used for projects that restrict some issues to managers only. Back on the issue. Security Schemes page under Actions, click Security Levels. Add a new security level with a name and description, and then click Add Security Level. For example, we add the security level of managers. Once you add the security level, you need to associate the level with the appropriate role or group. On the edit issue. Security Levels page under Actions, click Add.

Select a user group or role to add to the security level and click Add for great adventure. Violet needs to add the management group. Now you see the security level with the appropriate user group or role associated with that level. You repeat these steps to add and map other security levels. For now, let’s see how Violet associates the Issue Security scheme with a project. Navigate to your project. In the project settings, click Issue Security from the left menu on the Issue Security page, under Actions, choose select a scheme. You see the associate issue security scheme. To project project page. From the scheme menu, select the new scheme for the project and click Associate. Violet needs to use the Manager restricted scheme.

13. How to Modify and Delete Shared Schemes

As you work in Jira and develop schemes, you may find that you need to update schemes in existing projects. There are two scenarios to think about when modifying schemes updating the scheme itself, for example, adding an issue type to an issue type scheme and swapping one scheme for another in a current project. Let’s start with swapping a scheme and take a look at an example for this scenario. Remember, if you create a project using shared configuration, that project gets a copy of most of the default schemes associated with that particular project template. Later on, you may find that you want to change these schemes to something new or share a set of schemes with the project. Violet needs to do just that with the HR project.

At Great Adventure, she’s built schemes that work for several business departments at the organization using the finance project as a template. However, the HR project is current with active issues in the middle of their workflows. If she swaps schemes, she needs to make sure that the active issues make sense after the swap. So what can she do? Violet has a couple of options to help adjust the challenge of swapping schemes in the HR project. The first is Bulk move. And the second is the Migration Wizard. Bulk move may be useful for moving large amounts of issues over 500 and for using JQL to place issues into categories to move to multiple issue types. However, the Migration Wizard works well for smaller groups of issues that need updating for a single project.

In Violet scenario, she needs to update the actual schemes for one project. Switching to a new scheme prompts the Migration Wizard in the project, which allows Violet to update the associations. If Violet needed to update several issues to new issue types, she could still use a bulk move, but she would need to associate the correct issue type scheme with the project that contains the new issue types, search for the issues that she needs to move, and perform the bulk move. We talk about bulk move in another video, so let’s keep reviewing the Migration Wizard. If you have a project with a particular scheme, let’s say issue types, and you swap for a new scheme that doesn’t contain the old issue types, you need to migrate the issues to new types.

For example, if your old scheme uses planning and you need to move those issues to the event issue type. If the new scheme does contain the old issue types, you don’t have to perform any migration. For example, if your issue type scheme contains task and subtask, and you migrate to an issue type scheme that contains Task, subtask, story, and Epic, in this situation, the old issue types are a subset of the new issue type scheme. Finally, if you have a project that has no issues using the old issue types or statuses, you don’t need to perform a migration.

Violet needs to update the great Adventure Human Resources project with the new business schemes. As most of the business departments of the organization want to use a standard set of shared schemes, she gets to work on the HR project. The HR project includes active issues with statuses that are not in the new workflow scheme, so she needs to use the Migration Wizard. Let’s see how she handles swapping the workflow scheme. We recommend when changing live workflows that you test a staging instance before jumping right into altering your live instance. Violet, of course, has already tested her plan in a staging environment and knows she is okay to make these changes. She’s also taken into account the timing for her updates and warn users of the HR project not to transition issues during the update window. Because once a workflow migration has started, there’s no way to pause or cancel mid migration. We talk about testing and troubleshooting workflows in another video, so stay tuned. Navigate to a project where you need to update a scheme on the Workflows page. Click switch scheme on the associate workflow scheme to project page. In the Scheme menu, select Business Workflow scheme, and then click Associate. As a result, you may need to update the mapping so the issues show the appropriate new status on the Associate Workflow scheme to Project page. In step two, update any issue types current status to the new status based on your new scheme, and then click Associate. For great adventure.

We need to update task person and event. We update the Done status to close, and we update each issue types to do status to open something to consider. The Migration Wizard does not allow you to split one status into multiple, and you may need to further update an issue status after completion. A great example is the issues from the HR project were set to open, but because the old workflow only had open and done statuses, there were no in progress statuses. Now the HR manager can go in and make the appropriate changes based on the new workflow. When we’re done, we click Associate. Once you map issue types to Workflow statuses in the Migration Wizard, you see a notice about this migration. Click Acknowledge to complete the migration. Check your workflow in the project settings to make sure everything is correct.

When working with multiple types of schemes in a project, you may encounter a situation where you migrate a project to a new scheme, but there are unmapped issue types which may happen in an issue type screen scheme or in a workflow scheme. If Violet didn’t start with the issue type scheme for the Great Adventure HR project when she mapped the workflow scheme, any unmapped issue types use the default jira workflow. In this particular example, the Business Workflow scheme maps the event, person, and purchase issue types to specific workflow. So any project using these schemes needs those issue types for the proper workflow to appear. Otherwise, the issue types fall under unassigned types and use the default sharing workflow to avoid this situation. Start with issue type schemes. If you’re going through a project and updating the schemes especially those schemes rely on specific issue.

Type mappings once you update schemes in a project, you need to check and remove any unused schemes in fact, it is a bad idea to check periodically for unused schemes in your Jir instance, you can review a scheme and look in the projects column to see if that scheme has any projects associations. If there are none, and you don’t need scheme for another reason, you can delete it. Make sure to migrate to new schemes before you delete old schemes. We’re going to walk through deleting an old scheme that grade adventure doesn’t need anymore. We’ll start by going to the issue type screen schemes page. We’re looking for a scheme that has no project associations like this one. Once we find what we need, we delete. And then we confirm the deletion.

14. How to Detail Jira Workflows

Workflows model the processes users go through in their DayToday work. They ensure users take the correct steps and help teams follow relevant compliance policies or regulations. Let’s talk more about workflows, looking deeper at how you use them. In Jira, workflows are made up of statuses, the state an issue is in, and transitions the connection between these statuses. Jira provides default workflows with project object templates, or you can create your own. There are two types of default workflows standard and simplified Jira Core and Jira Service Desk’s. Project templates include default standard workflows. These workflows may be simple, such as the task management workflow for Jira Core with only two statuses, or they can be more complex, such as the service request fulfillment workflow for Jira Service Desk, which includes several statuses like waiting for support and escalated. Jira also includes a default readonly workflow, the Jira workflow that you can copy to create new workflows.

You can edit all of the standard default workflows except for the readonly Jira workflow. In addition to adding statuses and transitions, you can add conditions, validators and post functions, which we discuss in separate videos. Simplified workflows come with Jira software templates. These workflows vary a number of statuses, but they have one thing in common all statuses can transition to all other statuses. This means you can easily jump an in progress issue to Done and then to in Review and then to todo. The simplified workflow allows users to transition issues on boards smoothly. If you picture working on a software board, you can see how the ability to drag back and forth between the statuses makes sense. Simplified workflows also allow for some additional configuration options for the project administrator. If a project uses a simplified workflow, the project admin can add statuses to the workflow via board settings. If you need to restrict the number of statuses in your instance, you may want to evaluate the use of a simplified workflow as board.

Admins can create new statuses when using one. One last item to note about simplified workflows they don’t include screens and transitions. The transitions happen instantly. For example, if you drag an issue from in review to Done, the issue transitions without a resolution screen. Speaking of dragging issues on a board, what’s the relationship between Jira workflows and boards workflows map to software board columns in Jira software? We don’t cover software boards in this course, so check out the Jira Software series on Adaptiveislearn to learn more. What kinds of workflows do you use in your Jira instance? If you have a more complex workflow, is there any way you could migrate it to a simplified workflow? A Great Adventure violet has several different departments with different processes, so she has many workflows to keep track of.

As more departments on board to Jira, she has more requests for new workflows. With these requests, she needs to keep in mind the following document shared workflows to help keep track of what projects to use. Which workflows? Consider documenting the pairings. This is recorded in Jira, but it’s a little hard to get to, so if you’re sharing workflows, it’s a quicker way to know which projects are affected by changes you make. Keep it simple. Limit your transitions and statuses so users don’t get frustrated or confused. In addition, keep complicated customization to a minimum so you don’t find yourself with extra work. Whiteboard work with the appropriate team to draw out the workflow and walk through use cases. This exercise helps you and the users define the appropriate workflow design to match their business process. Use appropriate terms.

Make sure your transition and status names make sense. For example, transition names should clearly indicate what action the user performs, but avoid any terms or acronyms specific to the organization, helping new users understand the process without knowing particular terms. And finally, train users on Resolved versus Closed. You don’t have to use the Resolved status in your instance, but if you do, make sure users know the difference in these statuses. Resolved means the issue has been completed but may need a final check. Closed means the issue is done and needs no further action. Let’s talk about workflow screens. Next, you can use screens on workflow transitions to capture additional information. As a reminder, screens hold fields in Jira and typically relate to issue operations such as Create, Edit, View, and Workflow Transitions.

So for a workflow transition, the screen pops up after the user clicks the transition. Violet is going to add a screen to the business workflow to capture an assignee when a user moves an issue to review, let’s see how to do that. Navigate to the Workflows page and when there, locate a workflow you want to update. For example, we find the business management workflow under Actions, click Edit. Once you click Edit, you edit a draft of the workflow and must publish the workflow before you apply it to Projects. Locate the transition you want to add a screen to, and you can do this in Diagram or Text mode. We select Diagram mode and then select the Ready for Review transition. In the window to the right, click Edit. Then in the window from the Screen menu, select the screen you want to use, and then click Save. For greater adventure, we select the Review screen. Once you save, you see the screen you chose listed next to your screen in the window detailing the transition. If you need to update the screen, go back into the Edit Transition window and make your changes.