Jira Visual Reference: Issue Administration | Dan LeFebvre | Skillshare

Jira Visual Reference: Issue Administration

Dan LeFebvre

Play Speed
  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x
41 Lessons (3h 35m)
    • 1. Introduction and Project Overview

      2:14
    • 2. Module Introduction

      1:07
    • 3. Understanding the Two Issue Types in JIRA

      2:51
    • 4. Creating New Issue Types

      6:04
    • 5. Using Issue Type Schemes

      6:41
    • 6. Deleting Issue Types

      5:15
    • 7. Module Introduction

      0:50
    • 8. Understanding Workflows

      4:33
    • 9. Overview of the Workflow Designer

      8:31
    • 10. Creating a Workflow

      10:00
    • 11. Transition Properties

      6:02
    • 12. Transition Triggers

      5:02
    • 13. Transition Conditions

      5:15
    • 14. Transition Validators

      5:41
    • 15. Transition Post Functions

      4:16
    • 16. Using Workflow Schemes

      7:51
    • 17. Deleting a Workflow

      4:48
    • 18. Module Introduction

      1:03
    • 19. Understanding the Concept of Screens

      3:33
    • 20. Creating and Configuring Screens

      12:08
    • 21. Screen Schemes

      5:38
    • 22. Limitations of the View Issue Screen

      4:31
    • 23. Issue Type Screen Schemes

      7:26
    • 24. Working with Screens and Schemes

      8:29
    • 25. Module Introduction

      1:07
    • 26. Understanding Fields

      2:01
    • 27. Working with Fields

      9:53
    • 28. Field Configurations

      5:22
    • 29. Field Configuration Schemes

      5:02
    • 30. Module Introduction

      0:44
    • 31. Time Tracking

      8:24
    • 32. Issue Linking

      4:41
    • 33. Module Introduction

      0:56
    • 34. Statuses

      5:42
    • 35. Resolutions

      5:22
    • 36. Priorities

      4:44
    • 37. Module Introduction

      1:22
    • 38. Issue Security Schemes

      9:02
    • 39. Notification Schemes

      10:07
    • 40. Permission Schemes

      9:32
    • 41. Course Conclusion and What's Next

      1:16

About This Class

In this class we'll cover all of the features in the Issue Administration of Jira. While many online tutorials intend for you to watch them from start to finish, this class is intended to be a visual reference meaning you can hop in at any point to learn exactly what you need.

We'll start by covering Issue Types in Jira. We'll learn what they are, how to use them, how to create them and how to apply them to projects. Then we'll learn what Workflows are, how to create them and dive deep into the various transition options we have for them. Along the way we'll learn about Workflow Schemes to apply them to projects.

From there we'll keep moving along as we learn about Screens, Fields, Issue Features, Issue Attributes and many, many more features in Jira.

While this class is not necessarily intended to be something you watch from start to finish, this course is intended to be there when you need it. To be that reference guide you can jump back to as you're working in your own Jira instance. That said, of course you are welcome to watch it from start to finish so you can get an incredibly in-depth look at exactly how you can administer issues in Jira.

Transcripts

1. Introduction and Project Overview: in this course will learn all about the issue administration area injera. So I thought for the first video, we should set up some expectations for this course. This is not a course that you'll need to dedicate your time toe watching from start to finish. In fact, I've designed this course to be a visual reference library for you, something you can watch when you're setting up Vera. Or at any point when you're making changes. Maybe you're having trouble figuring out exactly what transition validators do or what our workforce schemes and how do they work. Or maybe you're just needing a little refresher so you can get over that one roadblock that's been nagging at you all day long. With this course, you'll be able to get in, learn what you need and then get back out so you can apply your new knowledge in your own gear installation. For that reason, most of the videos in this course are intended to be watched on their own as standalone lessons and will be moving pretty fast. So if you're not familiar with the basics of Jura, I would highly recommend checking out my other course understanding juror for users managers and admits first. This course, however, is intended primarily for administrators who want to dive deeper into each of the sections in the issue area of Jeers administration. We'll start by learning about issue types, what they are, how to create them and how to associate them with projects using issue type schemes. Then we'll move on to work flows. How to set those up what they can do for our projects and go in depth on some advanced workflow transitions. Some of the other features that will cover in this course our screens, custom fields, controlling field configurations across different projects to do things like making a field required in one project but not another one. But we won't stop there will learn how to work with issues, security to hide certain issues, from users in our Jiro instance, notifications to control, who gets e mails from Jura and how to set up permissions for different users to do things like managing sprints. And there's so much more. We'll take a look at just about everything that there is in the issue administration area to get a good sense of what we can do with issues inside of Jura. So with that, I hope you enjoy this course and find it helpful as you dive into the issue administration area of Ghira. 2. Module Introduction: in this module will kick off this course by learning all about issue types. Injera. We'll start by understanding the two types of issue types. Injera. Yeah, I know that consomme confusing. Trust me, it'll make sense. Then we'll move on to learning how we can create new issue types and how we can use schemes to associate those issues with projects Finally will wrap up this module by looking at a few things to keep in mind when creating sub tasks and deleting issue types. Now it's important to keep in mind that you don't have to watch every video in this module because of the incredible flexibility and customization that you can do injera. There's no way I can create a single course that shows you how to do everything for your specific scenario. So instead, I've designed this entire course to be something that you can use as you're setting up here or even as something to keep in your back pocket, as you need to make changes later on. With that, I hope you enjoy this module as we learn all about issue types, injera 3. Understanding the Two Issue Types in JIRA: in this video, we'll get a better understanding of the to issue types and gear up. So injured. Just about everything is about sorting issues, their stories, bugs, epics. They're all a type of issue now. The terminology here is really confusing, but it last. Ian boils down these issue types into two types of issue types. There's a standard issue type and a sub task issue type. So these are all of the issue types injera that come by defaults, others bug, epic improvement, new feature story task and sub task. Now by default, these six are what Jiro refers to as standard issue types. And then this one down here is a sub task issue type, so sub task itself is an issue type. But sub test is also a type of issue type. So that's why it could be a little bit confusing as far as the terminology is concerned. Just to kind of get a better understanding of this, there's the standard issue types. So Bug is a standard issue type. Epic is a standard issue. Type improvement is a standard issue, type new feature story task, and so on are all standard issue types and Then there's a sub task issue type, and one of those sub task issue types just happens to be called sub task. So it's a little bit on the nose, but you can create whatever sort of sub task issue type that you want and call it whatever you want here, inside of gear up. Now, the way that these different issue types work injera is that you're going to have your standard issue type that is basically the parent in the hierarchy. And then sub task, as you could probably guess, is going to be the child in that hierarchy. So, for example, let's say we have a bug standard issue type. So Bug is a standard issue type, and then sub task would live underneath that standard issue type. Same with story. Same with feature requests. These are all just examples of the different standard issue types and then the sub task issue type beneath it. All right, so now that we have a better understanding of what the to issue types are in, our next video will look at where we can create or edit them inside of Ghira 4. Creating New Issue Types: In the last video, we learned that there are two types of hee types. Injera. In this video, we'll learn how to create new issue types. All right, so let's start by going to our issue administration area so you can come up to the top right hang side. Go to the Cog under Jiro administration. Go to issues Now. I do want to point out that throughout this entire course, we will be spending time inside this issues area of Jiro administration. So really, you'll need to be Ajira administrator in order to perform these tasks that will be doing throughout the duration of this course. All right, so these are the default issue types that are created injera. As you can see, there's a type column and then under here it's either a standard type or a sub task type for the issue type. And that's what we're referring to in the previous video, so I won't really cover them here. But if you want to get a better understanding, I'd recommend watching the previous video where we go over kind of understanding the two types of issue types here inside of gear up. But what you need to know, as Ajira administrator is, before you create a new issue type, you'll want to figure out if you wanted to be a standard issue type or a sub task issue type. Now, In my experience, it's normal to have more parent or so or standard issue types. Rather, since those are the ones that you'll create first and then you'll probably have less sub task issue types. So in order to create one, let's come up here to add issue type. Click on that button and let's give this new issue type a name, maybe something like customer question. You don't have to give it a description, but I would recommend giving them discretion descriptions that way. Uh, your end users will kind of get a better idea of what to use the issue. Type four. So maybe this is to be used for initial customer questions before we know if it's a bug or not. So we can always move between the issue types if we want to, so we can create at first as a customer question. Then, if somebody and maybe in Q A, determines that it is actually a bug, they can move it over that sort of thing that you don't get Tana bugs that aren't really bugs getting submitted. Um, and here's where we determine the type of issue type. So I'm gonna leave this as a standard issue type. Add this in and we get our new issue type that's been created. Now, once we have it created, we can come back in, edit this and we need to change the name, the description. Or we can pick the image that we want to be displayed for this issue type so we can pick from any of these default icons that juror gives us or we can even upload our own. So let's say we wanted to use this guy here open that confirmed Very good. And now we have our issue Type avatar has been created. We actually need to hit update so juror will save this and great. We have our new issue type that we've created called customer question. It's a standard issue type we added in Ah, nice avatar for it. Now, the process for creating a sub task issue type is exactly the same. All we need to do is come up to add issue type maybe let's call this to do This is another type of sub task. Ah, we can choose a sub task issue type had add and you'll notice down here. Now we have our new sub task issue type that's been created now One thing I want to point out over here on the left hand side is the sub tasks menu. Now, if we go over here, this is basically the same as what we had for issue types, except it's just four sub tasks. The one thing you'll notice here, though, is the ability to disable sub tasks if you want. So this is a global option across all of Ji era. If you want to disable sub tasks so they won't be available to anyone inside of Jura and Onley, work with standard issue types, then you can disable them here. We can also translate them to another language if we want. If I open this up in a new menu, you can see if you have multiple languages that you're dealing with, you can actually translate as the name and description and so on to a different language. I'm not going to do that here, um or we can manage them. If we click on manage, it takes us right back to the issue types, which is where we were, and we can come in, do what we did with our customer question. Maybe add an image to it. What's select an image? Maybe we'll use this exclamation something we really need to dio firm and great. There we go. We have our avatar. So in this video we learned about issue types. We created a new custom issue type called customer Question. We also created a sub task issue type called to Do, and we added in our own custom avatars as well. So now that we have our new issue types created, there's actually one more thing we need to do before we or our end users can use them inside of JI era. We need to tell Jura what projects we want to use them in. Now we'll do that with schemes, and we'll look at those in our next lesson. 5. Using Issue Type Schemes: In this video, we'll learn how to control what projects the issue types are available in by using issue type schemes. So let's come into our issue administration area, the top right hand side, go to issues and then over here on the left hand side, let's go to issue type schemes. So, as you can see, we already have a couple of schemes set up. There's the default one and then one for each of the new earned the new projects that we've created injera. So by default, when you create a new project injera, it will create a new issue type scheme for that project. Let's come in and create a new one so that we can see how this works to create a custom issue type scheme. I'm gonna click on Add issue type scheme and let's give this a name. So maybe this is our Dev issued type skiing 2.0, and we can drag in the issue types that we want. So that's dragging some of the custom issue types that we created. Maybe customer question, maybe story, maybe improvements, maybe task we can bring in our to do so. That's our sub task custom issue type that we created Weaken set the default issue type that we want. That will be the one that Jiro highlights First, when somebody hits the create button up here at the top to create a new issue Ah, we can say Let's have story. Be the default. Now how we sort these over here will determine the order that Jiro users will see them in when they create a new issue. When they click on this, create button. So just so we can see what I mean by them will open up a new tab. Click on create so you can see this drop down here. Right? So the order that these are seen in will determine by the order that we have them here. So this is just a personal preference on my part. But I like to have the default issue type B on top and then anything that we want underneath that. So this is actually already in alphabetical order, So we're good to go. The sub task here will not show up here because these air standard issue types you have to create a sub task underneath a standard issue type. So when you're done, adding in the issue types that you want to your scheme it saved. And now that we have our new scheme created, we need to associate it with a project so you can see it's not associated with any projects right now. So let's click on associate here. We can tell it we want to use it in the Web Development team project Click on Associate. So if we come across this issue, essentially, what Ghira is saying is, Wait a minute, you're you are creating a new issue type scheme. And on that issue type scheme, you do not have this issue. Type the bug issue type. However, there are already bug issues inside of the Web Development Team project. What do you want to do with these 13 issues? So if we walk through this, jeer A is going to force us to migrate those issues to a new issue, type one of the issue types that we dragged over into the scheme. If you don't want to do that, you would have to add the bug issue type to our scheme. So let's walk back and do that. I'm going to click on the back button. Let's go back to the issue type schemes. Let's edit this and let's add in the bug issue type. There we go. So all the others are alphabetical, except for that one. The default. Say that. And now if we associate this, we should be able to walk through without any sort of an error from Ghira. So you can see it just went ahead and associated that with the Dev team. And now if I cancel out of this click on Create on the Web development team now we have our new custom issue type that we've created Associate ID with this project came just double check. Let's actually come in and create an issue real quick. So let's say possible Teoh new playlists just ah, sample issue here. Um, and let's creates this issue now. If I open this up, I should be able to create a sub task or create the to do sub task rather that we added to this scheme. So click on the three dots here, go to create sub task and there we go. So the one issue type that I can create is the sub task. There we go sign this to whoever we may want. They want to sign that Tasha. They would go create that, and we have a sub task that's been added to our customer question. Great. So in this video, we learned how to create a new issue type scheme and set up the issue types that we created in our last lesson on that scheme, her last lesson rather on that scheme. And we also looked at how we can associate that scheme with a project and then how we can edit this scheme to make sure that we're not missing any issue types. If you remember the bugs issue type, we forgot to drag that over, and we had some bugs in the project. But what if we want to get rid of an issue type before we conclude this module? Let's move on to one last video where we'll look at deleting issue types 6. Deleting Issue Types: in this video, we'll take a couple minutes to learn how to delete issue types. So the process of deleting an issue type is very simple. All we need to do is to click on delete here, except when the issues hype is in use, which is very common. So it may seem simple, but it's actually not as simple as it should be. So that's why we're walking through this here. So as we can see, there are six current issues that are the improvement issue type, and we can't delete this issue type as long as those issues still exist. So what we need to do is we need to actually migrate those issues to something else. Now, in this particular case, Juror is not ableto walk me through the migration right here because, as we can see, it needs to be associated with one workflow field configuration and field screen scheme across all projects. Now, we haven't looked at field configuration and field screen schemes in this module. If you want to learn about that, we will cover those in a future module. So let's walk through another way that we can migrate all of these so if we click on this number here, you can actually see this is a link. If I open this up in a new tab will get a search result with all of the issues that are the improvement issue type. So if we wanted to delete this issue type, what we would need to do is to change the issue, type on all of these issues. So to do this, I'm going to click on this little three dot right here, Click on bulk, change all six issues. Now, if you have different number of issues, it'll obviously say, however many issues you have, I want to change all of them. So I'm just going to check all of these. And what I want to do is to edit the issue and change the issue type from improvement. Let's change it to a new feature. So basically, we're changing it to something other than improvement. I'm going to uncheck the send mail for this update that will not send a notification email to each person. So anybody who is associate ID with the improvement issues that I'm updating would get a notification that those were sent, But I don't really want to send all of these people a notification. So I'm going to uncheck that. Just verify that, Okay? This is going to change to a new feature. All of these issues I'm not going to send updates. And yep, that looks good. So I'm going to continue there we go. Gear is gonna go through the process of bulk editing those issues. Once it's done, it will let us know. We can acknowledge that it's been finished now. There are no improvement issues. And now if we come over here, let's come back to our issue types. Let's come into improvement. Let's see if we can delete this now here is going to say Are you sure there's no matching issue types, but it's going to be removed from all of our field configurations are issued type screens are our workflow schemes. Basically, it's going to be deleted from the Jura existence as it were. All right, so I'll click on deletes. There we go and we have completely deleted the improvement issue type from this Jiro instance. Now the process for deleting sub task issue types is exactly the same, although the one thing I do want to point out, if we actually use thes sub tasks menu over here, we can delete them from here as well. So you can see there's no matching issue types you can cancel out of that. I don't actually want to delete that one. I just want to point out that you can delete them from here. Um, if you wanna make sure that you actually deleting the sub tasks instead of accidentally maybe accidentally deleting the actual issue types over here. So just to recap, deleting an issue type is very straightforward. We just come in, click on delete. Ah, for sub tasks, we Can you delete them here or in the sub task menu over here? However, if you have issues that are inside of that issue type, you need to migrate those to a different issue type before Jiro will let you delete the issue type here on the back end. All right, so that wraps up this module about issue types. Now, in our next module, we will learn about work flows 7. Module Introduction: in this module will learn about work flows. Injera. We'll start by learning the concept of work flows and why they're important to the way that jury uses them. Then we'll take a look at creating our own work flows and some of the advanced capabilities of work flows with transitions before starting to apply. Work flows to our Jura projects using workflow schemes. Finally, we'll wrap up the module by looking at how we can clean up unused work close like every module in this course. While obviously welcome to watch it from start to finish, you don't have to. In fact, I've designed this module to be a collection of videos that you can watch individually to learn what you need as you're setting up Ghira on your own. So no matter which video you choose to watch next, I'll see you there 8. Understanding Workflows: in this video will take a few moments to understand what work flows are and how they fit into Ajira. Now work flows are the structure that you, as Ajira administrator, set up to control how issues move from one status to another status. Think of it like laying down a train track except instead of something physical, like controlling where a train goes, you're controlling something a little more conceptual. You're controlling the path that issues take injera to get from one status to another. So let's take a look at an example workflow. Let's say that there are three status is to dio in progress and done Now, when a new issue is created, injera we have to pick from these statuses. So Jeron knows where it fits in the process, since new issues typically haven't had any work done on them. Yet, it makes sense to create a new issue as to do or in the status of, to do so. Let's say we have our issue that's been created. It's in two Dio now, as our Dev's are working on it, they want to be able to update the status to show that they've started working on this issue. So that means we need to be able to tell Jura that issues that come from the to do status can be moved into the in progress status. Now, as you can probably guess, the final step of our workflow will be to mark the status as done. Now that's all well and good. But in the real world, there's never just one bug for a Dev team. So what if they pulled the wrong one over? What if the Dev team marked this issue as done, But it's it's not really done. Maybe since they pulled the wrong one over, they want to be able to put it back to to do because they haven't really started working on this one. It was a different one that they pulled over. Or maybe they don't even want to show that it was in progress. Maybe they started working on it, forgot to drag it over to in progress, and they just want a market as done. That means that we would have to show Tell Jiro that issues from to do can go into the status of done. Or maybe they thought it was done and they pushed the code, and it was everything was good to go. But then now Q A. Kicked it back. There is actually more work that needs to be done, or it wasn't actually done when they marked it done Well, that would mean that we'd have to tell an issue from the done column that it can go back to the in Progress column to keep working on it. So, as you can see, it may seem very simple in the perfect world. But we don't live in a perfect world, and we really need to be able to tell Jura exactly where we want all of these to go. Now. As the gear administrator, you can control all of this with your workflow. Fortunately, in most instances you'll probably want to let your team to move them from any status to any other status, so you don't have to set all of this up manually if you don't want to. Now, if that's the case, we can just tell Jeer A that it can move from one status to all statuses. So this would tell gear that something from to do could move to in progress or done or something from in progress Tune can move to to do or done, and from done, it can move to in progress or to do basically it can move toe all statuses from any other status with this sort of a set up. All right, so hopefully you have a better understanding of just how much control we have with work flows. As you can imagine, depending on how you have jurors set up the number of projects issue types. All of it can add to the complexity of what your work flows need. Or you can keep it super simple like this here and just have a few simple statuses. It's completely up to you to build out a workflow injera. You'll need to get familiar with the workflow designer, So let's go ahead and move on to our next video. Where will actually jump into Jura and get an overview of the workflow designer 9. Overview of the Workflow Designer: In this video, we'll get an overview of the workflow designer, So let's start by going into the issue administration area here, click on issues and then click on work flows on the left hand side. Now, before we actually get into the workflow designer, I want to point something out about this page right here. Now, on this page, we can edit an existing workflow or create a new one. Now we'll look at creating a new workflow in a different video. So for the sake of this video, let's edit an existing one so we can see what one looks like in the workflow designer before we try to build one from scratch. Now there's something else I want to point out here, and that is, we have active and inactive work flows. So what's going to happen if I edit an active workflow? Let's say we want to edit this Dev project workflow. If I click on edit, Jura is not going to allow me to actually edit an active workflow because there's end users out there that are actually using this workflow. So if we edit it while they're working on it, it could screw up their status isn't and screw up their workflow. So what gear is going to do is when I click on edit, it's going to create a draft of that workflow we can see here. And then it's going to have me edit that draft. So I'm editing the draft. You can see right here, too. I'm not actually editing alive workflow, so I could make whatever changes I want and then publish this draft in order to change this workflow. All right, so this is the workflow designer. Now, if you did not jump into this view, if you jumped into a view that looks different, you may have jumped into the text view. Now, the text view is basically the same. It's just a different way of viewing the workflow. And you can still access everything you can access in the ah, in the workflow designer. I just prefer the more visual view. So I'm gonna hop into the diagram here because this is actually the workflow designers What this page is called. All right, So starting at the top left here we have our bread crumb, which is going to take us back to a list of work flows Exactly the same is clicking on this link. Here we have the title of our workflow and the ability to edit that. No, because I'm editing an active workflow. If I click on the pencil icon to edit the title of my work flow, you'll notice Aiken Onley edit the description. That's because even though I'm editing a draft of this, it's still an active workflow. So I'm not going to be able to actually edit the title of this workflow without making this an inactive workflow first. So let me hop into my work. Flow is real quick just so we can see what this looks like. I go to inactive. Maybe let's click on one of these to edit. Now, if I click on the pencil icon, you can see I can change the title of this workflow. So in order to change the title of your workflow, you have to deactivate it first by removing any active schemes workflow schemes that are applied to it. Now we'll look at schemes and how to do that in a different video. I just want to point that out. If you're trying to click on this to edit the title, and you don't see that because it's an active workflow. All right, so moving down, we looked at the diagram and text buttons already kind of what they dio. We have the ability to export this work. Plus, we can either export it as XML. Ah, this is really helpful if you want to back up your workflow locally, if you want to make some scripting changes to it or whatever you may want to do. It's worth pointing out, though, that when you're working on Jura Cloud, you cannot import work flows from XML. That's on Lee if you're hosting Jura yourself locally, so that's something to keep in mind when you export is XML. Now, if you export as a workflow, this lets you share your workflow on the Ajira marketplace, and you can import work flows from the marketplace using jeer a cloud. Now this area right here. This is actually Technically, this is what's referred to as the workflow designer, um, starting with the top left. Here we have the ability to add a status, so any status is that we have created in our gear instance, and once again we'll have a video that is dedicated completely to how to create a new status. You can click on this in order to add any of those statuses into our workflow. We can add a transition so the transitions are going from one status to another when it makes that well, when it makes that transition from one status to another. Juror calls that a transition, so it would go from one status to another status and then in that transition weaken. Tell Jared to use a different screen. Now we'll look at transitions later on in a different video. Will also look at screens how to create those. I just want to point out that this is where you can do that. We can add that into our workflow here. Ah, we can tell Jared to show us the transition labels, so you notice when it do this, it's showing us down here in the workflow designer. This transition is for create, so that's actually what this guy means, right? Here's when a new issue is created, it's going to go into the to do status. So if we wanted to change that, we would have to click on this and drag it to a different status here and now gear is going to say, Are you sure it's gonna change the destination of when you create an issue? It's going to automatically be placed in progress. I'm not actually going to do that. But if you wanted to do that, that would be how you'd actually change that here, inside of the workflow designer and then over here on the right hand side, you can see here's the edit, so Jiro will automatically save. Periodically. You'll notice there's no actual safe button. Jura automatically saves whenever you make a change, and you can see that status right here. And then here is the full screen button, so that's just going to making a little bit bigger. So you can really just focus on creating your workflow. And then down here in the designer is the actual workflow itself. So you can see I have looks like I have five six statuses total, so to do in progress, said the Q. A needs fixes approved by Q and done. Those are these statuses that I have, and then I have the transition that all statuses can transition to each one of these, so rather than setting them all up manually. I just said any issue can go from to do to in progress to send a key way to any of these, and vice versa really cross any of the statuses. And of course, we have the ability to zoom out or zoom in if you want. And I'd really recommend using these to zoom in or zoom out if you want, because if you use the defaults on the browser, so if I hit ah, control minus on my keyboard, you can see Jury is gonna pop up a little warning, saying it's not really designed to work when you zoom in or out on the browser. So you want to be at 100% on your browser and then use this to zoom in and zoom out. All right. So that is a look at the workflow designer, just kind of a general overview, getting familiar with what were close look like in the workflow designer. So let's move on to our next video, and in our next video, we're going to take a look at creating a workflow here in Jiro 10. Creating a Workflow: in this video, we'll look at how to create a workflow injera, right? So let's come into the issue administration area and then over on the left hand side will find work flows. Someone click on this and let's come in and add a new workflow. So click on the add work for a button on the top, right? And let's get this guy name. So maybe this will be our bugs workflow ad and by the fault will be taken into the workflow designer What we looked at in our previous video. Now you can see there's two things that get created in here by default. So this grey dot right here indicates that a new issue is created A When a new issue is created, this is the transition line for an issue. And then this is thes status law. Zinj. So right now what we're seeing, I'm just left clicking to pan around here. Um, what we're seeing here is when a new issue is created in this workflow, it will come into the open status. So, by default, every new issue that's created that's using this workflow is going to be added to the open status Now we can add more statuses in here if we want to. Let's maybe add in something like in progress, add. We don't have to use a drop down box. We could actually come in and start typing it in if we wanted to. And then any status is that we already have will show here. We could also create a new status here if you wanted to. Um, I'm not going to do that. My personal preference is to actually add all of the status is that I need over here in the issue attributes area. And we will cover this area in a different video in this course. So, um, usually when I'm working in a workflow, my personal preference is to already have everything bill already have. All the status is built that I needed them going to use. And then that way I can just focus on organizing them into a workflow. So minute used in review add that in now. You'll notice there was ah, little check box there. So if I come in, maybe add in just a couple more. Um, maybe something like needs fixes. I can tell you're to allow all statuses to transition into this one. Okay, so what this is going to do if I hit? Add on this, you can see there's a little all tag. So this is the transition into this status, just like what we have right here. Except the difference here is the only way to get into the open status is when a new issue is created. Once the new issue is created, it's going to be able to transition into needs fixes because we've told Jiro that any status can transition into needs fixes. But over here, for these two, you can see there's no incoming transitions. That's what this little red dotted line means. You can see jurors telling us right here. What this means is there's no way for an issue in this workflow to become either in progress or in review. We would need to tell jurors how to get issues to transition into this status, and I'm noticing there's not a complete status here. So I'm gonna come in and maybe do done allow all statuses to transition. All right, so we can see this. Ah, the different colors here again, we'll look at the different colors and what the categories are there. Um, but basically we have three different categories here inside of Jura. You can see the different color coordination and it's based on this statuses and that once again, that's all set up over here. All right, so in this workflow, we can either have issues connect from all statuses into this certain status. So if you wanted to do that, we could weaken either uncheck or we can check this in order to bring that transition back . We can also get a very fine level of control over exactly what statuses can be used. If, let's say for this open here, let's say we only wanted to go from open to in progress, right? We don't want it to go from open to in review so we can left click on these little dots here. You notice the cursor changes left, click on any of these and then dragged them into one of the dots on another status legend. So let's drag this into in progress to see what happens. What is going to do is going toe pop open this transition here Now we can either create a new transition or we can reuse a transition. We don't have a transition here to reuse because there's none coming in here, so we'd have to actually create a new transition here. I just want to point out that if if you do have some, you can reuse them here. Such create a new one. So this would be open to in progress. I'm not gonna give it a description. I'm also not going to add in a screen. Now, we're not gonna be covering screens in this video, But if you're not from on your screens, you can learn more about them in module for I just want to point this out here because if we wanted a winning issue transitions from open to in progress in this workflow, we could tell Jared to pop open any screen that we have in Algeria installation. So ah, if we wanted to pop open and force somebody to then assign it to another person, right so we could add this screen, and then on the screen, we could tell the field to be a required field. So that way it won't continue until they actually fill it out. Um, that would be done with a combination of screens, which again will look at in this course and also fields and field configurations to set that field into a required state again. We'll look at all of that. Ah, in this course, Um, but I'm not going to set one here in this example. Someone ad, and we can see what has happened. We have a transition line going from open to in progress. Okay, so we can either set up each of these transitions manually, or we could simply come in and tell Jer to allow all statuses to transition into this one. Now, in my experience, unless there is a very specific need to set up individual transitions, it's usually a good rule of thumb to start by allowing all statuses to transition into this one or into each status. And the reason for that is really because of human error. It may sound great tohave this Onley go into in progress, but a lot of times I found that in the real world, maybe somebody accidentally transitions status. They actually drag it from one column to another column on an agile board or, um, they dragged the wrong one. Maybe they think that it was this issue. But no, it was actually they pulled the wrong one over. Well, if you get it locked into a certain status and they can't get out of that status without having to go into review or something like that, all of a sudden people are going to start asking you that your administrator for helping how to get this status, to go from one to another if they just made a simple mistake. So, um, usually, I like to give my teams the benefit of the doubt and the trust just to be able to transition between any status that they need to and give them that freedom. Um, once we have this so you can see we have both of these. Really? This is just gonna override this one? Um, there's the only catch there would be if we did have a screen or something like that, This would pop up going from open to in progress. We could do that. We can also apply any of these options if we wanted to know we're not going to cover those in this video. But over the next couple of videos, we're gonna be looking at all of these different options to get an idea of what each one of these Dio. But for now, I'm gonna come in, select this transition, delete the transition, and that will remove that. So now our workflow essentially is that once an issue is created, it will be able to go into an interview. Obey were to go into in progress, it will be able to go into needs fixes it will be able to go into done and vice versa. Once it's in any of these status is the last thing that I'm going to do in here is for open . I'm also going to slit this to allow all status sister transition again. Just because of that human element is somebody accidentally drags a ticket that's open into in progress. And then they realized, Oh, that was the wrong ticket. I need to drag that issue back. Um, this will allow them to drag this back into open to to do that. Okay, so this is a very simple workflow, of course, but the process is going to be the same. No matter what workflow you use, it's really just a matter of how what the status is. Are that you're bringing in the transitions and how they all kind of connect together. So just as a recap, the workflow that you'll use is to add in the statuses, hook them together and whatever way that you need. And I would highly recommend going to chat with the team leader or the manager of whatever workflow Now that's going to be affected by whatever workflow is that you're creating to get an idea of exactly how they need this to go together before you actually come in and start building it. All right. Now, a few minutes ago, I actually did mention the options over here for our transitions. So in many cases, you may not need to touch them, but if you want to learn more about them, will start to take a look at them in our next video. 11. Transition Properties: in this video will dive deeper into transitions and learn about the options and properties for them. So let's hop into the issue administration area and come into work flows. And for the sake of this video, I'm gonna pick on this dead story workflow because it's an active workflow. And that way we can see the changes that were making without actually having to worry about hooking up a workflow with the scheme and things like that. So come in and edit this workflow, and by default you'll notice if this is the first time editing a workflow. Jura is going toe automatically create a draft workflow. So in order to see our changes, we're going tohave toe. Publish that draft. And the reason for this is because when you're editing an active workflow, that means and users in your giri instance are actually using that workflow. If there having issues that are moving along your workflow so you don't want as you're making changes. If, until you actually done with all of your changes, you don't want to screw up with your script your end users by, um, changing things on them until you're actually done. So basically That's the reason why Juror forces you to edit a draft and then have to publish that. So let's come in. And I'm gonna pick on in progress here on a select the actual transition. When I do that, we have this little pop up that happens over here. Okay, so up top, we have the ability to edit our transition so we can change its name of who want to. Ah, we can add a screen if we wanted to do that very similar to what happened when we actually created a transition. Um, all of those options there we can come back and changes if you want to. We can delete the transition. Who wanted to do that? So if we wanted to get rid of that transition and then maybe manually add in some transitions, we could do that as well. Select this and bring that back. And then down here we have our transition options, and this is really where all of the power in transitions like there's five different options, and we're gonna take a look at each one of these in this module. But let's start with the properties. These are our transition property and this is probably the most advanced of the transition options. The reason why I say that is if I click on this were taken to a page that Ghira pretty much gives us absolutely no indication as to what transition properties are or how to use them. Now, probably one of the best ways to understand transition properties is to simply just take a look at what they look like in action. So, American Men and let's add a key. So I'm gonna type in ops bar sequence, maybe give this a property value of zero it ad. All right, Now that we have this, I'm gonna come in close out of this tab, come into this ah, satis going to its transition properties, I'm going to do the same thing. I'm going to give this a UPS bar sequence and let's give this a value of 10. All right? So basically, what we've done is in progress is gonna have a value of zero. This is going to have a value of 10 on the ops bar sequence. So the question would be what is the ops bar sequence? Right. So before we actually publish this, I'm gonna hop over to a Web development story. So something like this here. So his story in the World Development Team, which is what this workflow is hooked up to. So this is the operations bar right here. And this is the sequence, Really, For these statuses are what we're going to be controlling. Okay, so you can see right now, done is first in progress is second. And what we've done is if we publish this, we should see she's I hit, publish and then hit Refresh. We shouldn't see that's flop, right. The reason for that is because we set a value that's lower on in progress, then on Done Now, if we had more status is either probably be a little drop down here, but we can control that order or the sequence on the operations bar by giving it a status or value rather inside of the transition. So again, on the transition, the properties of the transition for that status we gave that property value. Okay, so that's just one example and actually here, I would refer to let's pull this with other window open here. So if you do a search in at last year's documentation, you will find a list of the property keys. Okay, So the property keys here, you'll find a list of those over here in their documentation. And I would highly recommend checking this out because I met last thing. Keep this up to date. So if they add any, you'll find them in here. Here is the ops bar sequence that you saw and then a basic example of how you would use them. Okay, So as you can see, there's really only handful 1234567 There's only seven keys available. So the transition properties is really only seven different things that this is going to be able to do for you inside Algeria. So the chances that you're going to be using this are fairly slim. Um, but that is a look at how transition properties work and how you can use them here inside of Jiro. And with that that wraps up this video. So in our next video, we will take a look at another transition option with triggers 12. Transition Triggers: in this video, we'll learn what transition triggers are. So let's hop into the issue administration into work flows and edit an active workflow. Now, like the name implies, a transition trigger is something that automatically runs when something else happens. I'm gonna happen to the diagram view, just another way of viewing our workflow. My preferred view is the diagram view, so just kind of be consistent throughout this course. So if we select our transition, let's pick on this all transition for the in progress again, hop into triggers. And fortunately for triggers, Jerry is going to tell us what a trigger is. So unlike properties, if you watch the last video of Jared doesn't give him it's insight. What triggers it does. So basically a trigger is something that happens externally outside of Jura. That then triggers this transition inside of Jura. So for trigger toe work, we actually need to hook up an external dev tool, one of these listed here bit bucket stash, fisheye or crucible. Um, and as if Jura at lasting rather adds more connections in there, they will update this, but those are what's currently available. So when in one of those external tools. If you have that hooked up, say a pull request happens right then that transition will happen inside of Jura. So let's look at how we can hook this up. Okay? So to begin with, I'm gonna actually need toe link an external tool. So I'm going to use my bit bucket account as an example here. And that's gonna be something that we do outside of the issue administration area. So I'm gonna hop into applications when open that in a new tab, go to the D. V. C s accounts. And over here I can link my bit bucket account. Okay, so I'm gonna link that you could use get cub if you prefer. Ah, with bid bucket already have an account created. I'm already logged into that account so I can grant access. Once we have that, then we actually need to have access coming the other way. So once we have it linked both ways, we're good. It will sink very, very cool. So now that we have this, if we come back over to our transition, I can refresh this page here and we will see that we can add in a trigger So let's add in maybe something like when there's a new branch created inside of bit bucket, then with this trigger source that we have hooked in, What's going to happen is when a new branches created in bit bucket, it will automatically use this transition. Okay, so this transition, if you remember, is in progress and this is incoming into in progress. You can see the arrow there. So as soon as a branch is created with an issue that is linked to the issue in question inside of Jiro, that issue will then transition to in progress automatically. And we can set this up for each status, right? So maybe if we had an interview status inside of our workflow, we could set up when there's a poll request in bit bucket, we could have a transition to in review or something like that. You could do some really cool automation with triggers, but there's a few things to keep in mind. So if we hop back into transition here, you can see these caveats again. Cheers. Telling you the conditions validators and permissions will be ignored for automatic transitions. Okay, so we have other videos in this course that air covering things like conditions, validators, those air actually in this module as well as permissions on issues. All of that will be ignored because it's happening automatically so that whoever is assigned to that issue, or whatever conditions you have applied on the transition, all of that will be ignored by these triggers. So that's something to keep in mind when you set these up. Okay, so that's all that there is to setting up triggers. As you can tell, it's actually easy to do. As with most things here, injera, the most complex part is knowing how you want them to be set up. So it'll work best for your team, which transitions you want them to do when there's a pull request commit and so on. And, of course, with any of these, once you're done, you actually need to publish your workflow in order to actually see all of these changes live. All right, so that is a look at transition triggers. Knowing our next video, we will take a look at transition conditions 13. Transition Conditions: in this video, we'll learn about transition conditions. All right, so let's happen to our issue administration area and over into work flows. Now a condition tells Jura Onley to perform our transition based on whatever our condition is. So let's pick on this in progress Transition here come into conditions. Now let's add a condition. Okay, so this will make more sense as as we're going through it. So if we add in a condition, let's say maybe a user is in group. You can see there's a lot of different conditions that we have here. Add in a simple one here. So let's say if a user is in the Web development team it ad and you can see right away exactly what this is going to do. So on. Lee, users in the group Web Dev team can execute this transition. So, for our particular instance, in this jury installation, if I come into user management up here, come into the groups, go to the Web Dev Team group. That means one of these three users will be the Onley users that can transition an issue into the in progress status inside of this workflow. That's what this condition will do. But what's one thing that's really cool about transitions is that we can actually have multiple conditions in order to really control who can execute this transition. So let's add another condition. Let's say maybe the Onley assign any condition. Okay, so I come in hit. Add on this now either the the Web development team, right? So either it has to be either Barbara, Natasha or Steve, and they have to be the assigning. So if there's an issue that's a scientist and Tasha, then Barbara and Steve will not be able to transition this. However, we could change this and say any of the following conditions, and that opens it up completely. What that means is, then, if there's a user in the Web development team, so again, these three users can transition an issue into in progress or any user in our jeer instance , if they happen to be the assigning of an issue, it doesn't matter if the in the Web development team group or not, because we told your that any of the following conditions will work. As you can tell. There's a lot of power here, and I'm gonna add something else in here just to kind of show exactly how much power we have. So let's say on this assigning, let's say, let's add in a group condition over here and let's say, value field for issue type. Find that here, There we go. Condition equals bug. All right, so, Addison, and then we'll get an idea of what this is doing. So now, in order to transition and issue to in progress in this workflow, either they have to be the user whose whose? Requesting the transition. Er, actually initiating that transition has to be in the Web development team group or they have to be the assigning of the issue. And it has to be a bug, right? So it cannot be a story or one of the other issue types in the workflow. Does that make sense? So what we've done is we've grouped this together. So now not only does it have to be the assign me, but it also can Onley be a bug issue type because we've added that in again. We could say any of these if we wanted to um but we can get a fine level of control by grouping together our conditions. So basically, that is how conditions work. We're controlling whether or not someone can execute that transition using any of these variables. And, as you can tell when we came in here and added a condition, there's a ton of different options that we have a ton of different options at highly recommend you come in, take a look at all these different options again. It start to get an idea of all the different conditions that you have to see how they will work for your team. I'm willing to bet the chances are very good that you'll be able to get your to do exactly what you want with conditions here. So I'm gonna cancel out of this. And just as a reminder, any time you're making any changes, if we want this to be in effect, we actually have to come in. Publish that draft. If you're working on an active workflow in order to actually see it take effect. All right now, in our next video, we will keep learning about transition options as we look at transition Validators 14. Transition Validators: in the last video, we learned about transition conditions. In this video, we'll learn about another way of controlling our transitions with Validators. So let's hop into issue administration and over toe work flows. Now, conditions and validators are very closely related because they're both ways that we can control, whether or not the transition will happen based on a certain set of criteria. So let's pick on this in progress. Transition again. Come into validators. Click on this. Now we can come in and just like we did with with conditions. If you watched the previous video, we can do this with validators with the validator, essentially, we can boil down whether or not the issue will transition in this case transition to in progress using a bullion. Is it true or false? That's basically what validators are. So let's add in a validator. Maybe, let's say a field required validator. Okay, so ah, in this example, let's say that we're we're using capture for jeer. A capture is the test session management tool inside of gear to be able to have your maybe your cue, a department run test sessions on various things. Let's say we want to make sure that in the test sessions that they're using with capture, they added in the operating system. Okay, so we can add that in that will now be a required field before the issue can transition to in progress. This field will have to have some sort of information in it. Okay, If it does not weaken, add in an error message. Oh, I forgot to add the capture Forge era operating system. Something like that. We can give our end user an error message toe. Let them know why the transition is not happening. Okay, So if I come in here, add, we will have this validator so basically again, Jerry is showing us what this is going to do. If the value for the field that we added in capture for Jura operating system is not provided during the transition, then it will show the following error. So maybe our Dev team is getting tired of receiving bugs that don't have the operating system added. Well, we could make sure that that feel this is filled out using a validator. Of course, in this particular case, this assumes that your team is using Juries capture feature for Q A testing. You'll also notice that we don't have the ability to choose any or all of these validators like we did with conditions in the last video. Basically, this is true or false. Does it validate, or does it not validate if it does transition? If it does not, don't transition so we can come in. We could edit this if we wanted to. If you wanted to add in more fields. If we wanted added meal, make sure had label make sure had whatever sort of feels that we want. Ah, again, we can edit the error message if we wanted to and update that just like conditions, which we learned about in the last video again, we can add multiple validators. So let's say maybe a previous state validator. Okay, So in addition to requiring a field, we also have to make sure we want to make sure that this issue was currently in review. All right, so it had currently went through the in review status. We can tell jurors if we want to make sure that that was the most recent status. So it's coming directly from in review to in this case in progress, since that's the transition that we're working on, or maybe not the most recent. It's just that it has been in that status we could add in that validator and again, yes or no, is that. Does that validate? If so, then it will transition. In this case, if we have multiples than what we're doing is we have it has to have both. So for an issue to transition in progress in this workflow, it has to have both values in this field, the capture for Ajira operating system field and the labels field. And it also has to have been in the in review status prior to this transition trying to take place. If all of these conditions are, all of these criteria rather are valid are are yet, yes, the answer is true. All of these are true. Then Juror will allow this transition to take place. So to recap, transition validators give us the ability to validate that Something is true about that issue. Ah, field of status permission level of the user. As you can see here, there's a lot of different things that you can check for before letting Jura transition and issue now, if you haven't already, I really recommend checking out the conditions video just before this one. Conditions are really powerful, and validators are really powerful. But together, conditions and validators are an incredibly powerful way of making sure that everything is exactly as it should be before letting a transition happen. All right, so that is a look at transition validators. In our next video, we'll take a look at post functions. 15. Transition Post Functions: in this video, we'll take a look at post functions for transitions. So I hop into issue administration and toe work flows. If you've watched any other videos in this module, part of getting kind of used to this process of coming in here. So just as an example, I'm going to be using this dev story workflow same one that we've been using in the previous videos. And again, we will happen to the diagram view. We can get to the transitions using these links here. But I prefer to be consistent since we've been using the diagram view when I hop in here, going to all for the transitions and we have our post functions. All right, so we have Ah, all of these other things here is well, but we've been creating those. You'll notice there's already five post functions on this transition. And the reason for that is because Juror already has some post functions that it adds by default. And post functions are a little bit different than the other transition options that we have that we've looked at in this module. The primary reason is right in the name they happened after the transition their post functions. They don't happen before the transition. They happen after the transition. All of these other things the properties, the ah triggers the conditions, the validators. Well, maybe not the properties. Those air we saw those were actually just on there, no matter what. But these three the transition is the conditions and the validators all happened before the transition takes place. They are how we make sure that the information is correct before the transition takes place , or whether or not the transition will even happen at all. Once that transition takes place. Weaken Tal Jura to do something afterwards so you can see there's some defaults that added in here. And we can't even edit a lot of these. You can see Jura won't even let us edit many of these. But we can come in and we can add around. So let's add a post function here to see what some of these options are that we have. Let's say OK after this issue, transitions to in progress, we want to maybe update a field. So we updates, maybe the assigning. We could do that. Let's say we wanted to assign it to a specific user. Maybe a sign it to Natasha. Okay, so a soon as this transition happens, so when somebody takes an issue from either in progress, open or done transition to the in progress status in this workflow, at the very end, it will be assigned to Natasha. Now, Hashem may not appreciate this assigning all of these issues to her, but you can kind of get a sense for how post functions work. Maybe instead of the assigning, we want to come in and change that. Maybe we want to set set the priority. We can change the priority to medium. Um, maybe the Dev team is getting, ah, lot of bugs that are always high priority. Well, with this, we could set the priority to medium and again in conjunction with conditions so we could set the condition to make sure that okay, it can only move to this status If it's ah, bug, right. We could set that condition based on the issue type and then ah, set the post function to be set to medium. So with all of these different options, we can really, really find tune the level of control that we have over our work flows. So just to recap, post functions are things that will happen after the transition has taken place. That in and of itself is powerful because we can use it in conjunction with triggers, conditions, validators, all of the things that we've learned about to make sure everything is organized exactly how we want and organized smoothly and again, like any of the transition options that we've looked at In order to actually see this take place for year end users, you're gonna have to actually publish that into an active workflow. All right, now, with that, we've covered all of the transition options. So in our next video, we will take a look at workflow schemes. 16. Using Workflow Schemes: In this video, we'll learn how to use workflow schemes. It's always hopping to the issue administration area. Over on the left hand side, we will find workflow schemes. Now workflow schemes are how we tell Jiro what work flows to use for which projects by default when you create a workflow. If you remember from the video in this module we created a workflow. It's not applied to anything by default. It's not going to be active. No end users are going to see it until we added into a workflow scheme and associate that scheme with the project. But more than that, workflow schemes also apply to issue types. This makes things extremely flexible because we can have multiple workflow is going for a single project. Let's see this in action. I'm gonna add a new workflow scheme. Ah, let's maybe call this our Dev Project Workflow scheme. All right, so we add this in now by default, we only have this one work for This is the default Gerald Workflow. What this means is as soon as we apply this scheme to a project, any issues that we create in that project all on a side issue types will follow this workflow. Right? So issues created it will be open. It could move to resolve. It can move. Teoh closed. It will follow this workflow. That's the default, Gerald. Workflow. We want to change this. We can come in. Let's add a workflow when at existing If you want to add one from the at last seaon marketplace if you download one externally, you can do that. I'm gonna add one that I've created. Okay, so this is the workflow that we created in a previous video in this module. We can add this in. This is the bugs workflow. And this is where naming convention comes in handy because you can call us whatever you want, but because this is called bugs workflow. I know that I created this with the intention of using this for the bug issue type. Okay, so assign that to bug it finished. All right, now what's going to happen is a new issue is created. It's gonna follow this workflow. Unless if that new issue happens to be a bug issue type, it will follow this workflow that includes the statuses that includes the transitions, the transition options that conditions the validators. Everything that's associate with this workflow will become active as soon as we apply this scheme to a project. Now, we could come in if we want to change this, maybe want both bugs and new features. We could do that. We can assign that we can remove that if we wanted to. That's what those actions do over there. So let's set up this scheme in some way. That would make sense. So at Bugs back in for bug finish. Let's add in another one. Maybe our story workflow. So that's the one that we set up for story issue types. Maybe we want our default one. So are deaf project workflow. This will be the default. So if I hit next when a sign that to all unassigned issue types and you're gonna give this little warning right here because we already have a workflow assigned. So as soon as we apply this, it's going to remove this workflow. This is the default juror Workforce. I'm OK with that. It finished. And now this is the way our scheme is set up. Okay, so if we create an issue and it's a bug, it's gonna follow this workflow. We create an issue and it's a story. It's gonna follow this workflow right here. If we create an issue and it's anything but a story or a bug, it's going to follow this workflow. Okay, So as you can see with schemes, we have a lot of control over exactly which workflow is going to be used in our project. But before we actually see this in action, we would need to apply it to a project. Okay, so we have this scheme, Let's apply this to the development team project. Someone come into projects. We have our Web Development team project and over into our work flows. Let's switch the scheme right now. It's using the default workflow scheme. Switch the scheme to use the one that we just set up. That's our Dev project workflow scheme. Associate that now when we do, this, jury's gonna go through this little, uh, this little wizard. Basically, what it's saying is, um, all of these different issue type so these are all zero, which means they're zero issue types with that. Ah, this one right here. So this is one issue type, So there is one to do issue type in the Web Development team project. However, because in this project we don't have that status available. Okay, are we don't have that These status is available to them. So Jere is gonna be asking, How do you want me to map this? So, for the to do issue type, how do you want me to map open, reopened, resolved and closed? Weaken? Tell it to do this however we want. So maybe to do, to do resolved, maybe would be done. Clothes will be done. These are based on the categories of those statuses. Same with this. Here to do is fine. Done done for those two. Once we have all of this associate ID, I'm leaving these blank because there's no issue types here. No issues are issues affected, rather not issue types. And associate juror will go through and map all of that to migrate all of the issues to our new workflow scheme. Very cool. And now, if we want to see this in action, what's happen to our ah Web Development Board? If I open this up in a new window so we can see give myself a little bit more room here so we can see we have on this board. We have different issue type. So this is story. This is a bug, right? And because these different issue types are now following different work flows for the bug weaken, take this and we can drag it to in review. We can drag it to need fixes, weaken, drag it done any of these statuses? However, for a story issue type we can't drag it to interview needs fixes on Lee to done because we've set up a workflow where this issue type is applied to a different workflow than the bug issue type. And that workflow on Lee has the ability to transition between from in progress to done right. So we've limited what statuses can work in that particular workflow. And then we've applied that to a particular issue type using our workflow scheme. So just a recap. Every project has toe have a workflow scheme. That scheme is used to map work flows to issue types. The simplest set up would be to have only one workflow that's assigned to all on assigned issue types or if we need, we can get a ton of control by adding work flows different issue types using workflow schemes. As we've seen in this example. Now, if you've watched some of the other work full of videos in this module, you've probably noticed that we can't edit an active workflow. You're automatically creates a draft forest. So what happens if we need to get rid of a workflow? Well, we'll take a look at deleting work flows in our next video. 17. Deleting a Workflow: in this video, we'll learn how to delete a workflow. I saw us come into issue administration go into work flows Now. Deleting a workflow may seem like a very simple and straightforward process, and it is once you know how to do it. But it's something that could be rather frustrating if you haven't so let's take a look at this. As you can see, we have all of these work flows, but there's no ability to delete it would show up over here under actions. That's because these are active work clothes, so you cannot delete an active workflow. You can actually see jurors telling us this right now, so to delete a workflow, we have toe unassigned at first. The reason for that is because if it's active, that means there are end users that are using that right now. So if we delete it all of a sudden, here is not going to know what to do with the issues that are being moved around in that workflow. So we have to replace it with something else first. So down here, once we have something inactive, we can delete it as we can see what this guy here. Ah, these are actually built in work clothes that are defaults. And Juris Oh dear Will not allow us to delete the built in system work flows. So let's walk through the steps of everything we need to do to actually delete. Let's say we want to delete this bugs workflow. Okay, well, a lot of this. There are things that we've covered in this module, but let's walk through this. I'm gonna come into the scheme. Open this up. We edit this workflow scheme, we can come in and let's remove bugs from this workflow. Remove that once that's done, we have to publish the changes on our scheme just like a ah, an actual workflow itself. We cannot actually edit an active workflow scheme. We would have to your automatically creates a draft of that and then we have to publish that when we do, this year is going to say Hey, wait a minute. There are 13 bugs that are using this workflow and a new workflow that is going to go into So is going to be this Dev project workflow. Why is that? Well, if we cancel out of this real quick and hot back to our scheme. You can see why that is. Um that is for all on assigned issue types, right? So as soon as we remove bug from this scheme, all of a sudden bug became an unassigned issue type, because the only issue type that we have a signed this story. So if I want to publish this now, we have to tell Jiro what we want to do with all of the bugs that are in the open status and the in review status. Because this deaf project workflow does not have open or in review as a status in that workflow. Now there's two things we could do here. One we could hop into the depth project workflow and change that workflow. So it does have these two statuses. And if that's the case, it would migrate without any issues. Or we can tell Jura to map this to a new status. So maybe open will become to do in review can be in progress. Okay, When we associate, that jury's gonna go through the process of updating migrating all of those issues, changing the statuses that are affected when that's done, our workflow scheme has been published and it's now active. We did not have bug workflow in here anymore. So now if I close out of this, this bug's workflow should hop down to inactive as soon as I hit. Refresh. There we go. So it's not there. Now it's inactive. And now I can come in and actually delete this workflow. And I really like this little warning that jury gives. It is confirmation you wanted delete it, but it lets you know you can't undo this. There is no under the no recycle bin. There's no trash folder. As soon as you delete this, it's gone. However you can export it. Just click on this little link right here now will export it as an XML file that you can back up and you can always bring it back whenever you want. So I'm gonna delete this. There we go. Our workflow has been deleted. It's no longer there. So just a recap. If you're needing to get rid of a workflow, you need to first make it inactive. You can do this by making sure that the workflow is not being used in any workflow schemes . You can see which schemes are assigned to a workflow here in the work flows area of the issue administration section. All right, so that is a look at how you can delete a workflow. 18. Module Introduction: in this module will learn all about screens. Injera. We'll start by looking at the concept of screens. Then we'll jump into Jura and create and configure our first screen. Then we'll learn all about screen schemes before looking at some of their limitations. Finally, will wrap up the module, learning about issue type screen schemes and then putting it all together in a single video as a quick reminder. Each video in this course is intended to be a video reference that you can use to get in, learn what you need and then get back to using your new knowledge in your own gear. Instance. However, due to the nature of screens, screen schemes and issue type screen schemes, learning about one relies very heavily on the others. So if there was one module and recommend watching all of the videos in order, it would probably be this one, Of course, depending on your existing knowledge of Ghira, maybe you're already familiar with some of the features. So no matter which video you choose to watch next, I'll see you there 19. Understanding the Concept of Screens: in this video, we'll take a few moments to understand what screens are and how they fit into Ajira. So basically, you can control which fields will show up with screens. Maybe you want your screen to show a description. Text field for your end users to be able to type in details about an issue, or maybe the assigned the field so your end users can assign the issue to someone else on your team. Or maybe you want to display custom fields that you've created. You could control what the end user sees and then, by extension, what they can fill out, since they can only fill out what they can see. All of this is done with screens. Now here's an example of how a screen works injera. All of these on the left hand side, our fields. There's due date status, assigning those are all different types of field, and then those air displayed on the screens and then on the other side. The end user can interact with them. So even though there's a lot more than just those three fields, if they're not displayed on the screen than the end user can't interact with them. But obviously, that's not exactly what it looks like inside of Juris. So here is an actual screen inside of Ghira, and just to get an idea of which, what the fields are on the screen. So the project that's a field right, the issue type. That's a field. The summary. That's a field reporter in the field, even the component, Even though it's not filled out right there, it is a field. Even the description itself is a field. So let's say, for example, what if we wanted to hide the component? Maybe we don't ever use the component field, so we don't really need that showing. If we're not going to be using it, all it's going to do is just take up space on the screen, and we can use that space for maybe another field or just make things look a little bit cleaner. We can remove that from the screen and just make it disappear. Now we could bring that back at any time. The field still exists. We are just not showing it on this screen anymore now, because the component field is invisible. Obviously, that means no one will be able to fill it out or to change the values of that field again. It's not deleted. It's not removed. It's simply not visible anymore. We can make it visible at any time by bringing it back onto this screen, or we can hide it at any time by taking the way from the screen now. But as you can probably guess, this is just one example of a screen and only one example of removing a single field from a screen. There's plenty more that we can do is screens, and we'll be taking a look at all of this throughout this module. But hopefully this gives you an idea of what screens are and how you can use them to control what your end users will be able to fill out. As simple as this concept seems, it can get even more confusing when you start throwing schemes into the mix both screen schemes and issue type schemes. So, just to recap a screen injera is basically what the end user will see to fill out fields and information. Injera Great. Now let's move on to our next video, where were learned how to create a screen injera 20. Creating and Configuring Screens: in this video, we'll learn how to create and configure screens. Now, as with most things injera, there will be some screens that come pre installed for you. So before we create around, let's edit one of those, and that will help give us a great idea of what to expect. So let's hop into the issue administration area, come into your administration issues and go to screens on the left hand side. Now editing a screen can seem a bit tricky at first because of the terminology. So if we click on edit here, really, all this does is has us change the name and description of the screen itself. It's not actually editing the actual screen. What we want to do is to actually configure the screen, and this is pretty consistent. Injera. If you see, edit and configure for something injuries, administration editing will let you edit things like the name and description of the field itself or the actual component itself that you're working on. Whereas configuring well lets you will configure whatever it is that you're wanting to change. All right, so let's configure this. So this is a list of all of the fields on this screen over here on the left hand side. If you hover your mouse over this, you'll notice that the icon changes. So this is fairly straightforward. We can click and drag in order to rearrange this. However we want from top to bottom course, we can click on the remove button toe, actually, remove something. Say, if we want to remove the priority, we could do that and see the priority is no longer there. But how does this look to the end user to see what that will look like? We'll need to go where this screen is being used. So this is the bug screen. So I have a new tab open here. Let's go to the bug. And this is what this screen looks like. So you can see all of the fields that are on this safe who wanted to remove the component. We can come over here. Take this. Remove it Now we would have to refresh this page. You don't have to refresh the entire page. All we have to do is to switch away and then come back. And then Gerald Whoa, refresh a recall That screen every time that we pull that up so you can see the The component is no longer visible on this screen. No, I want to point out that this is not the only place that you see a screen. Ah, this screen that we're looking at happens to be for creating an issue. Now there's also viewing an issue and editing an issue that have different screens, and we can control what screen is shown with screen schemes. So if you want to learn about controlling which screen is shown for which operation, check out the video on screen schemes. And also, if you notice we're actually controlling the bug issue type in the DEV project so we can control what screen is shown by which issue type using, issue type screen schemes. So again, if you want to learn about that, check out the video for issue type screen schemes. All right, let's move back to our configuration of the screen here, and we can actually bring in any fields that we want down here. So let's say we wanted to bring in something like a due date. We could do that now. It'll pull it at the very bottom by default, so if we Well, if you scroll down, you'll see there's no due date down here. I need to actually refresh this. So that's got a story and doesn't really matter. I'm just going to a different issue type. We could go to any of the other issue types because the idea is to go to a different issue . Type to show that issue types screen and then come back to this one to refresh this screen . And now we can see the due date. Field is here now, back in the configuration, you notice there is no save because it's automatically being saved as soon as we make a change. So as soon as we click and drag this, it will be changed and we'll see that change reflected as soon as somebody hits that screen for the next time so we can see this due date has been moved up, and that change is live as soon as we make that change. And we can't even bring in any of the custom fields that we've created. All of those will show up down here, So if you want to create a custom field, check out the video on custom fields for how to do that. As soon as you have your custom field, it will show up here. We can add it in either by looking for in the drop down, or you can start typing and looking for it. So say, if we wanted to bring back components, that was the custom feel that we built or whatever we wanted, we could actually do that. Bring that back and show it up here on the screen. Now, as we start to add in fields, the screen can start to get clotted if we just add in a bunch of stuff. And that's where tabs come in handy. So you can see this is the field tap here we can add a new tab. Let's say we want to call this all of our, um there we go. So our sign e so weaken. We have a sign me over here. Let's pull this out. Let's may be removed at take out the way, the remover, anything that has to do with users. We could do that so we can bring the assigning of here and bring in the reporter over here . Maybe call this something like users. Actually, just a clarify a little bit more. More than just the assigning. So now if we come over and take a look at what this will look like, You see, we have two tabs now so we can add a little bit of organization weaken, clean all this up. So it is not. Maybe you're not scrolling down so much, right? We can do that with tabs to really help organize the screens and, um, add a little bit more, well, organization to it. Now, one thing I do want to point out, and this is just something coming from my own experience. You know, working in jail myself, as well as with some clients that have worked with is sometimes users don't find the tabs, so they simply just ignore this right here. And then they're looking Well, where's I can't assign this to somebody. How do I do that? You may want to. If you're instituting tabs into your screens, make sure that your users know about them. Really? That just depends on the size of your team high. You're going to do that. Sometimes it's as easy as an email showing a screenshot something like that. Sometimes you can just gather up the team real quick. Maybe in the morning. Ah, stand up and just let him know that Hey, we've got tabs on the bug screen now, so you can use that. Maybe just just for the Web Dev teams What? They're the only ones that it effects. Just let him know that Hey, we cleaned it up a little bit, just making a little bit easier. We added, in some tabs, there's anything you want to see added in there or removed. Just let me know. We can organize that however we want. All right, so that's a look at how we can configure screens now. The only thing we haven't looked at is how to create a new one. As you can imagine, this is pretty easy to do. The most difficult part is what we've already done, and that's configured the screen. Really, The reason why that's difficult is really to know how you wanna have it organized, and I would highly recommend before you come in and start configuring or creating a screen . Have all of that figured out. Have it figured out exactly what fields you want the or you want a man, if you want tabs, have all that figured out so you can just come in and do it right away. So in order to create a screen, let's come over here to screens on the left hand side again. Come in and click on add screen. Give it a name. So maybe my custom screen click on add. And then really, it's just coming in and adding in the fields that we want. So ah, one thing I do want to point out is that summary is a required field inside Algeria. The summary is something that jury uses, and it uses it outside of the screen. So by cancel out of this and do a search for issues, this is the summary here, right? And so, if, for example, of this is to create, if you put this on the create screen issue and there's no summary field, nobody can fill out the summary field and jeer A is not going to let them save the issue because it needs that summary to show across all of juror across really anywhere that that issue is going to be shown. And so if nobody can fill out the field. It won't work, so the summary field is one that's kind of special. It actually needs to be on their, especially if it's a created going to be a screen it's on create. Ah, the rest of this is pretty straightforward, just stuff that we've already looked at as far as configuring. And that's why I wanted to show configuration first. So we come in here with some fields already, and this is exactly the same as what we just did. You can add fields. You can rearrange them to add whatever you want. You know, drag him around, do whatever you want to do, adding tabs if you wanted to tow, organize them. Now, if we have back to screens over here, you'll notice that this delete link is only available for this one that I've just created. It's not available for any of these. You know, it's I can't delete any of those now. The reason for that is because the other screens are currently in use. Remember, Jura Auto saves the screen, so when you're editing one that's in use, it's gonna go live as soon as you edit it so gear will not let you delete something that's live that's being used. Otherwise, Jerry would not know what to do if someone tried to view that screen. If somebody was creating a bug in the Web development project like we were looking at and you had deleted this screen, Gerald wouldn't know what to do. It would error out so it will not let you delete it if it's being used. So if you want to delete a screen, you have to disassociate that screen through schemes. You can see the screen schemes that that's being used in right here. You can see the new screen that I created is not being used. So we can configure that however we want. And nobody's going to see it until we associate it with a screen scheme once. Once the issue is not, I'm sorry. Once the screen is not being used by a screen scheme, then you can delete it and you'll see the delete link show up here in order to actually delete that screen. And there we go. So we've deleted that screen that we just created. All right, so that is a look at creating and configuring screens. Now, if you need to control where your screens air seen in relation to creating, editing or viewing them. Then you want to move on to the next video, and that's where we learned about screen schemes. 21. Screen Schemes: In this video, we'll learn about screen schemes. So basically, once we have a screen created, we can control where that screen is seen. Using a screen scheme. Weaken. Tell Jared to display a different screen, depending on whether or not someone is creating an issue, editing an issue or viewing an issue. So let's get started. Let's come into the issue administration area and over to screen schemes. And let's add in a new screen scheme. Given a name may be called something like my custom screen scheme. Obviously, you probably wanna name it a little something more in line with what you're going to be using it for. But for our purposes, this example name will work. Now here we can tell Jiro what we want our default screen to be. So this is the screening we actually made in the last video. I actually went ahead and recreated that. I know we deleted it in the last video, recreated it and just added a few field. So we'll have something to be able to see once we put all of this together. But you can see this text beneath it. This is the screen to show for unmapped issue operations in the new screen or in the new scheme. So this will make a little bit more sense once we see what these operations are. When you create this scheme, you can see this is exactly what it just told us. The default for all unmapped operations If we click on Associate, an AP issue operation with this screen, if I could talk properly there, you can see what the issue operations are. There's create issue, there's edit issue and there's view issue. So what do these screens look like while we can choose which screen we want to use for each of these? Right. But let's take a look at what these look like on the front end. So I have a few tabs open here. This is the create issue screen. This is what this looks like, right? So depending on which screen we tell gear to use will determine what fields are in here. But this is basically what the screen would look like to get here. All you have to do is click on the create button up here at the top, and that will show the create screen. So anything that we choose with this issue, operation is going to be in this create issue screen. There's the edit issue screen. So in order to get here, all I have to do is to go to the issue and then click on edits or hit the E key on the keyboard in order to pull this up. This is the edit issue so you can see this right here, right? So we're choosing the screen for that. And then finally we have view issue. Now there's a few points to bring up about the view issue operation because you can see that this is a little bit different than either create or edit. The view issue has a lot of things built into it by ji era. So when we're telling Jura using our screen scheme that we want a specific screen to be shown for issue operation, this Onley works for custom fields. It will not work for the built in fields Injera. You can see a lot of these air already on here. The assigning the reporter, all of this stuff is automatically added into the view issue operation which is this screen right here. So really all we're telling jurors, which custom fields we want to add in and really there on Lee going toe work. The custom fields are only going to show up. They would show up right here in the details. They only show up if they have a value in the field. So if it's empty, it will not show up in this view issue field or this view issue operation. Rather, so I would highly recommend to make sure that you put any custom field you want to display . Also on the Edit issue operation. Make sure the screen that you choose for edit issue operation has your custom field. That way, someone can edit the field when they fill it out, and that way it will show up under view issue. So that is very quick. Look at screen schemes, however, is you probably guessed screen schemes don't work on their own. We haven't really seen fully what they can do, so I would highly recommend not only checking out this video, but check out the next couple of videos really the rest of the videos in this module, because we're going to be building on what we've learned and getting a good idea of how all of this works together. All right, so let's actually move on to our next video and we'll take a look at some of the limitations of the view issues screening we were talking about. See that inaction? 22. Limitations of the View Issue Screen: their last video. We learned about screen schemes, but as we learned, the View issue operation has a few stipulations to keep in mind. So in this video will continue on from what we're learning in our previous video and see those things in action. All right, so the first thing we need to keep in mind is that the view issue operation on Lee works for custom fields. Now, if you're not familiar with creating custom fields, be sure to check out that video in the Fields module. But real quick. We're going to go ahead and create a custom field toe add to our screen. So let's come into issue. Administration come down to custom fields. Let's add a custom field and again we'll cover this later on. So I'm not going to go over this real in depth here. Just add in a field that say real simple options or yes or no, this is a radio button. All right, so we've created this. Let's add this into the field for our bug and under the field tab. That's fine. Update this. There we go. And of course, we always need to do ah re indexing time we add a custom field, so I'll re index real quick. All right, so now let's come over and apply this to the screen scheme. So I'm gonna come in this way through this scheme because I want to make sure. Okay, Yeah, we have just one screen across all of them. I could have gone into screens, but I want to make sure that I'm getting the one for the view issue operation, cause that's really one of them. One of focus on here, so we only have one. So that's this here, and you can see it's been added in. So if I come over to a bug, we should see this show up. Right? Hit, refresh. Where? Where's my field? It's It's not there. Jura has this great little Tullow. Help us find the field. So I'm going to admin Where is my field? And let's start looking for the field. This is the custom feel that we just created. So now there's just gonna tell us where it is. You can see. Okay, So, yes, it is in the scope. I was in the field configuration. It's on the screen field value. This is where it's not showing up, It does not have a value. And so it will not be displayed on the view issue page. We need to set a value for that field for it to show up. So this is one of those stipulations. In order for it to show up on this view issue. Ah, Page. We actually need to have a value for that custom field. So I'm gonna e in order to edit this and let's come down, find this. Let's say yes. We love Jura update, and now we will see this field show up on the view issue page. Now, unfortunately, we can't really customize the rest of this view like all of this over here or kind of all of this here that's really baked into Jiro. So most of this view issue page isn't really as customizable, but that's a look. A The limitations of this view issue operation here in how we can get a custom field to show up on this page. So, just to recap the view issue operation on Lee works for custom fields and not really the built in fields that come with Ghira. The field also has toe have a value. So my recommendation is to add the field that you want to show on the view issue to the edit issue operation so that your team will be able to make edits when you come in and be ableto edit that field. All right, so let's move on to our next video. And in the next video, we're going to start to see this come together with issue type screen schemes. 23. Issue Type Screen Schemes: in this video will learn about issue type screen schemes. So with an issue type screens came weaken. Tell gear to show a screen based on the issue type. For example, we would show one screen for a story issue. Type in another for a bug issue type. Probably one of the easiest ways to understand how issue type screen schemes is to look at . One juror has created for us automatically when we create a project. So let's come into our issue administration here and come over to issue type screen schemes . And let's take a look at one of these. It's in action. Let's configure this in order to see. So here we can see this issue type screen scheme for the Dev Project so we can see the bug issue type is using the scrum bug screen scheme, and then everything else is using this default screen scheme. Now, if you remember from our screen scheme video, the screen scheme is controlling what screen shows up for, create, edit and view issues. So we're getting even more control here by telling Gereb what we want to show for creates, edit and view in our screen scheme. Four just the bug issue type or for any of the other issue types that are in this project. So let's see how we can customize this. I'm gonna come up to associate an issue type with a screen scheme and let's associate with the story. So this is the issue type and let's choose the screen scheme that we created before. And actually we may want to change the name of this just to kind of be in line with the others that we've had. But we can leave this for now. I would I would probably rename this to something like Dev Ah, story, screen scheme or something like that, to kind of give us an idea of what this screen scheme is controlling. So really, that's all that there is, too configuring an issue type screen scheme. So what we've done is we've told year to use this screen scheme for the story issue type, and we can see this in action. If we pop open a new window here, it creates let's go to our story issue type. We can see we have our summary reporter description assign e right. So if we come into the story here. Let's go to the screen scheme. And on this screen, we all we have this for really all of our issue operations. So we're gonna have this screen, which is our summary reporter description and assigning summary reporter description and assign me We can change this. However we want may want to add that custom feel that we created in a previous video. We can do that. Switch over to a different issue, type of them back to story. And we can see that being added in there if we wanted to maybe Onley show this on. Let's hop open this screen scheme here who wanted to change this? Maybe associate a different screen. Let's show maybe, I don't know. Just pull one of these other ones over here. The default four are create, right? So now this screen will look different If you come over, You can see now we have all this stuff here. But if we come into a story, cancel out of this. Find a story on the Death project hit edit You can see now this screen has our summary reporter description, custom field assigning, and then the edit automatically has the comment in there, you can see that there. So that's this screen, right? Because our screen scheme is saying for the create issue Operation Show the scrum default screen, which is this one here having all of these fields, but for everything else. In other words, the edits or view screen show this custom screen that we've created. So you kind of get an idea of how all of this starts to come together with the issue type screen schemes, and we've controlled that over here, saying for the story issue type show this screen scheme. Now we're working on an issue type screen scheme that has already been associated with the project. You can see it's shared by one project right here. So before we wrap up this video, I want to show how you can associate an issue type scheme with a project because that is not done in the Issues administration area. To do that, what we would do is come over to projects which would be appear come into the project that we want to edit. Come down to the issue type screen scheme so you can see what we have here, and we can associate or use a different issue type screen scheme with that project. So let's say we wanted to change this completely. We could go to the default associate that and now we have our default screens. So now if we come back to one of these hit refresh it edit, you can see our screen is gonna be completely different because we've associate ID our default screen. It's also going to be completely different for create. You can see here we have completely different fields that we have on here because now we're using the default screen for everything. And that's this screen right here. And that is how we would associate an issue type screen scheme with a project. So is a recap to this. An issue type screen scheme could be associate with a project and that lets us tell Jura to use different schemes for different issue types. And then those screen schemes are going to tell Jura what screens to use for creating an issue, editing an issue or viewing an issue. All right, so throughout this module we've covered some concepts that, quite frankly, can be rather confusing individually. We didn't always get to see these inaction because For example, you need to understand screens games before you can have issued type screen schemes. And really, you need to have screens before you can have the screen schemes, and it really just build on each other. So in our next video, let's wrap this module up by taking everything that we've learned so far in this module and see how all of it works together. 24. Working with Screens and Schemes: in this video, we'll take everything. We've learned this module about screens, screens, games and issue type screens games to see how they all work together. Now let's start by looking at what we want to create. So any time that we're actually building something in Jeers administration area, it's always a good idea toe. Have a plan ahead of time. Know what you want to create before jumping in to create it. That way, you're building what your team actually needs instead of what you think they need. So I'm gonna create an issue so we can see this screen here. We've been working in the Dev Project throughout this ah module. I'm gonna hop into the feature request project and let's say for the new feature issue type , we really want to clean Ah, lot of this stuff up in here. And for this example, my team said that they want to see an operating system field so they can track what operating system the feature request is for. So I'm going to get rid of a bunch of this stuff and then add in a custom field for operating system. So let's look at how we can do. This first step is to create the custom field. Now we have a different module in this course covering custom fields, configuration schemes. All of this stuff here, we're going to cover that. So I'd highly recommend checking that If you want to learn more about fields, I'm just gonna go through this process to kind of see how it all works together. And part of that is with fields. So let's use a select list. That way you can choose multiple things. So, ah, if its Windows Mac or Lennox or Windows and Mac or Windows and Lennox or all three we can do that. So operating system, the name of the field. So Mac Windows, the Knicks. And let's do this in alphabetical order here. There we go. Now, I have not created the field that I want to add this on to. So I'm just gonna ignore this screen and let's do a re index, which is something that General always wants to do whenever you create a new field, that's fine. Jury index real quick. Once that's done, it's hot back into the issue administration area. Let's create our screen, so I'm going to add a screen, and this is gonna go into the feature request project. So this is for the new feature, Screen it ad and let's add in our fields so summary that field is required by Girish. So it's one that is a good idea, have on all of our screens operating system. That's the new custom field We just created description. Sign me. There's some kind of basic fields, so that's pretty good. We don't need to save this because jeers automatically saving in the background. It's coming and create our screen scheme. So the screen scheme, as we learned in the screen scheme video, is going to tell Ghira where to use that screen based on the issue operation. So create at it or view. So I'm going to add a new screen scheme again. This is for the future Request Project, New features screen scheme and let's use the default as the new feature screen recreated. So I'm going to use this screen across all unmapped issue operations, and I do not want to add any issue operations, right? So what that means is, I'm going to use this new feature screen that created across creates at it and view. And again, this goes back to knowing what your team needs. Unless there's a specific reason to show different screens for those different issue operations. Our to recommend having this be your default of using one screen across all three. That way it's more consistent and end users always like consistency. Um, so I would recommend that kind of being your default mode of operation. So with our screen scheme created now, we need to create an issue type screen scheme. To assign this to the new feature issue type, I'm gonna come into the issue type screen schemes. Let's add in an issue type screen scheme. So again, feature request project. This is going to be for the UPS new feature issue type screen scheme. That was a quick side note. Here. You can see these names can get rather long. Um, always found the easiest naming convention is to be really a simple as possible. So this is something that's going to be on the back end that us the jury administrator is going to see the end users not going to see this name, so I usually default to using the project or the project key. First, the issue type that it's going to be used on, which is new feature and then really what it is. So this is an issue type screen scheme. It does get a little bit long, but it helps months or years from now when you're trying to figure out what is what. I just kind of try to be a straightforward as possible. Ah, the screen scheme that we want to use is not this new feature screen ski we created. I want to use the default screen scheme because this is setting for the unmapped issue types. So when you add this in, so for all of the issue types on the feature request project, I want to use the default screen scheme. Except for the new feature issue, type someone associate an issue type new feature when associate that with this screen scheme, add that in and now gear is going to use this screen scheme for the new feature issue type . For everything else in this project, it's going to use a different screen scheme. Okay, so we can see how this is starting to come together. The last step for this is to associate this issue type screen scheme with the project who would come into projects, come over to feature requests and let's scroll down to we find our issue type screen scheme . And let's change this to the new feature issue type screen scheme that we created Associate . And you can see we have to issue types here that are going to use this screen scheme and one issue type that is going to use the new screens came that we created. All right, so let's check this out. I'm gonna come back to the dashboard here so we can see this creates And there we go. So our new feature issue type is showing summary weaken Select one. We can select all we have our description, assign me very nice, very clean. And then the other issue types have very different screens and different fields on them. And again, we could come into the exact same thing for these different issue types showed different screens show whatever it is, we want to show these air both pulling from the same screen, so they're going to be the same. The new feature is going to be very different, depending on the issue. type we could control what screen and what fields we want to show. So just a recap. In this video, we created a custom field that we put that field in a new screen that we created. We applied the screen to a new screen scheme that told gear What operation? To use it on. So either create, edit or view. And then we associated that with the new feature issue type through an issue type screen scheme. And with that, we've come to an end of this module just as a quick reminder as you're working injera. Feel free to hop in and out of any video in this module or really any module toe. Learn what you need and move on. Okay? With that, I see you again in the next module. 25. Module Introduction: and this module will learn about fields injera. We'll start by understanding the concept of fields, configurations and schemes. Then we'll jump into gear up to see how we can create and configure fields before seeing field configurations in action. Then we'll wrap up this module by seeing how field configurations and field configurations schemes can get us a great level of control over the fields inside of Jura for Onley, the issue types and the projects that we want them to apply to. Now we'll be using examples in this module, but the techniques you'll learn are applicable to any sort of field configuration you may want to do in your own gear installation. Really, the sky is the limit, like every module in this course. While you're obviously welcome toe watch from start to finish, you don't have to. In fact, I designed this module to be a collection of videos that you can watch individually toe. Learn what you need as you're setting up Jura on your own. Thanks again for watching, and I hope you enjoy this module as we learn all about fields injera 26. Understanding Fields: In this video, we'll get an overview of fields, configurations and how they work together. Let's start by learning about the three things you have endured to help you create and customize your field. They are, well, fields themselves. The concept of fields is fairly straightforward. Ah, field injuries. Exactly what you would expect. Text fields, drop downs, radio buttons and so on those air, all different types of fields. Then there's field configurations. So let's say you have a field that's a radio button with yes and no options. Is it a required field? Or maybe instead of a radio button, you have a text field for comments, and you want gear to use its built in wiki style Render er for the text field. That's the kind of stuff you can set up with field configurations. Finally, we have field configuration schemes. Basically, this lets us tell JIA where to use the field configurations that we create. So if you watched any of the videos in the screens module, you're probably familiar with schemes injera. And you're probably wondering if screen schemes control what fields show up. Where, what do field configuration schemes do? Well, that's a great question if field configuration schemes don't control where fields are shown , but rather what their configurations are. For example, maybe we want this due date to be required for bugs, but not for feature requests. So you can see here it is not a required field with the field configuration scheme weaken. Tell it to be required on some screens and not on others. Okay, so that's a look at the different tools that we have for fields. In the next video, we'll jump into Jura to start learning about fields. 27. Working with Fields: in this video, we'll learn about fields now Fields and your are exactly what you think of when you think of the term fields. So let's hop into the issue administration area and come over to custom fields Now, as you can see, Juror comes with a bunch of built in field. Many of these are feels that you can't really edit, so you can see these are locked, which means we cannot edit the configuration of these fields. However, we can show or hide them on screens so you can see some of these are on a screen. And some of these are not if you want to learn how to add them or to show or hide them on a screen. Ah, hop into the screens module in this course to learn how to show or hide fields on screens. So let's take a look at how we can create a custom field. It's fairly straightforward. Let's walk through this process so click on Add Custom Field will be presented this list of field types, so there's a wide range of field types that weaken do. These are the standard types. There's also more advanced types. If you want. Let's come in and do a radio button. Give this guy a name. So maybe what is your preferred browser? And add in some options. So when you have an option, you can click on add, or you could just hit the enter button in order to add those in the enter button on your keyboard. Once you have all the options in there, you can rearrange them. However you want to using the little dots on the left hand side. You can also click on X in order to remove those options. Once you're happy with this, just click on create and your new field will be created. And that's pretty much all there is to creating a field. Of course, if you choose something else other than a radio button like a text field, you'll get different options than a radio button. What the process is the same Now there's a couple things I want to point out here. One. You'll notice a pop up box that's asking about re indexing. We'll come back to this in a little bit, but basically after you create a field in jeer, jeer if it needs to re index everything in your gear instance, so that that field can be added to the index and people can search four things in that field in your gear installation. We also have the ability to add our field toe a screen right here. Now we don't have to do this. This is optional. You can add it to a screen later if you want. Using the process that we learned in the screens module of this course, I just want to point out that if you create a field and it's not visible on any screens, then there's no way that end users will be able to add Ah, add information into that field. So the field that we just created that radio button, what is your preferred browser? There's no way that people will be able to answer that question if it's not visible on a screen. So typically you want to add it to a screen somewhere. And that's why Jiro defaults to I pushing you forward to this particular screen to associate the field with a screen. So let's come in and select the new feature screen click on update and then will be taken back to our custom fields. Now, before we do a re indexing, I want to make sure that we have all of our options correct. Otherwise, we'll just have to re index once we make those changes again. So let's come in and let's take a look at the options we have for our field here. What is your preferred browser? We want to make a change to it. We can come in to the gear icon, and we can either configure, edit, translate screens or delete. So let's take a look at these options. Just get an idea there. Fairly straightforward. Ah, but let's just take a look at each one. So delayed again. Straight forward. There is a confirmation page soon as you click on Delete that will be deleted but also gets rid of all of those all of the values of in that field. So anybody that fills it out, it's going to delete everything for that, so just make sure you actually want to get rid of it instead of hiding it. That would not delete it. That just makes it disappear from a certain screen. We have the screens page, so that's where we just were associates. This field with a screen. We can do it here. Also, do it through screens. As we learned in the Screens module, we have translate. So let's say if you have multiple languages in your Jiri installation, you can add a custom translation to which ever language you want. We also have edit and configure. So if you watched some of the other videos in this course, you'll kind of get the sense for what? Edit and configure our This is pretty universal. Anytime you see, edit and configure when you want to edit something that's going toe, have you change the name of whatever it is you're editing? So who want to change the name? What is your preferred browser? Will click on edit. We can change the field name at a description or change that if we added one in earlier. And then there's also the ability to configure. So if he wanted to change the options. So let's say we wanted to come in and add safari back in. We can edit the options here, add in safari, and then we can rearrange this. However you want using the arrows over here by order, so this will add all make it go all the way to the top can also add in our position. So let's say we want this to be first, 2nd 3rd and fourth just so that they'll be organized alphabetically. It move. There we go. If you want to change the title on any of these, we can click on edit in order to change the option name. Delayed the option. Disabled the option. Fairly straightforward options As far as those are concerned, once we're done here and we're happy with the way they say is we can click on done, that will take us back to our configuration. Now, this whole area here is has to deal with the configuration scheme. So we're not really gonna cover that in this Ah, in this video. But we will cover field configurations and field configurations schemes in this module so we'll take a look at kind what that stuff does later on. Okay, so once our field is has been built and we're happy with the options that we have, we can re index. So I'm going to click on Performer Re index and there's two options that we have for re indexing. Either one weaken. Do it in the background, which means that our end users or anybody will be able to continue using Jura while the indexing is taking place. Or we can completely lock everybody out of Jura and rebuild. Now this will be much faster, but this will allow people to use Jura, and I would highly recommend using the background re indexing. I mean, honestly, I've never even done the lock. Ghira. Um, I've had thousands and thousands of issues in Nigeria installation and had clients have tens of thousands of issues, and even with background re indexing, it only takes a few minutes to do. And so it's really not too bad. It's much better than locking everybody out and then having somebody reach out to the gyre , administrators say, Why can't I do anything injera? So as we select the background re index, tell it to re index juror will go through, do that indexing. You can see it's a fairly fast process, just going to take a few seconds to actually re index. And there we go. It's done. All right, so that is a look at Fields injera now Educ unsee. It's a fairly straightforward process of creating fields. Just a few things to keep in mind. The really The last thing I want to mention is, at least as of this recording, you cannot convert one field into another field. So if we wanted to convert this from radio buttons into something else, we cannot do that. Um, so what you really want to do is to learn what the options are for the different field types. So that way, when somebody comes and asks to be able to capture some new information or some new data inside of Ghira, you'll be able to create the right field the first time. Of course, users changed their minds sometimes, and if you do come across the need to actually convert something, basically, that process would be to, let's say, we want to convert this from radio buttons into a check box field. We would have to create a new check box field with the same options and then do a balk change on the data across Jura from one field, migrating it actually out of this field into whatever our new field is. It's a work around that can take some time, depending on how much you need to migrate over. So really, that's just something to keep in mind. Okay, so that's a look at Fields. Now, in our next video will take a look at field configurations. 28. Field Configurations: in this video, we'll learn about field configurations. So let's happen to our issue administration area here now, with field configurations weaken. Tell Jared to do things like make a certain field required or optional. It's come into field configurations, and, as you can see by default, there's only one field configuration. It's the defaults field configuration, very aptly named Now we could come in and add in a field configuration, but that would mean we'd have to hook it up with a scheme. And we'll learn about that in our next video. So for this video, let's look at the defaults field configuration just so we can focus on learning what field configurations are. So if we click on the defaults field configuration in here, we have every field injera. Now this page would look the same If we created a new field configuration. We just be configuring a different version of it. Remember, we're not creating new fields here were customizing how the fields we already have function inside of Jura. So no matter what, we need to have all of the field listed in here in order to be able to configure them. So let's say, um maybe attachment you can see here it is displayed on this screen in the field tab. We could hide this field across all of these screens by clicking on height. So let's come in. I'm gonna open up a new tab here so we can see this in action. And let's create on the deaf team the bug so you can see we have our attachment field right here. Now let's come in and let's hide this. There we go. We've hidden this field, You can see now it says show instead of hide. So now if I come in, switch to a different issue type and then back to bug, we can scroll down and see. We no longer can see the attachment field. So this sort of overrides the screens because we're telling here that no matter where this field is showing shown on, no matter what screen it's on, I want it to be hidden. But showing or hiding a field is not all that we can configure. And what we can configure depends on what type of field that is. So before I forget, I'm gonna show this again. Now let's scroll down and find some different types of fields. I'm gonna x out of this. We can do a re indexing at the very end of whatever changes we make. Uh, how about description right here. We can see. So right now with the description and again, that's this field right here. All right, so it is using the wiki style render. So the wiki style render allows us to do things like, um, adding in Click on this here, we can see what all of these different effects are, so we can add the, um, asterisk in order to make something strong can add underscores in order to add emphasis. All of that is because we're using the wiki style rendered. We can change that render here in the field configuration. So let's say we want to use just the default text render. So as soon as we do that, it's going toe update that for all of our description fields. So once again, we'll have to kind of refresh this. Go to a different issue type comeback We can see now. We don't have those little icons there. This field does. You can see this one does use that same render the wiki style render. But with this it's just pretty much plain text now at this point. So those are the kind of options that we can do. You want to switch this back to the weakest style render update that we can also make a field required. So let's say we wanted the description to be a required field again. Gonna come in and to actually click on that, make it required. Come over, switch to story, switch back to bug. You can see now this is a required field. You can see the little asterisk, Which means if we try to creates the issue, we have a summary. The description is required. You see here will not allow us to actually create this issue without that required field. And it's the same for any word that that field is being. You'd not just on this bug issue type, So this story also uses a description. It's also required here on this story. But what if we wanted Let's say we wanted our description to be required Onley four bugs for this bug issue type not on the story issue type. Well, that's where field configuration schemes come in and we'll take a look at those in our next video 29. Field Configuration Schemes: In our last video, we learned about field configurations in this video. We'll take it a little step further and look at field configuration schemes. So by default, if we come to our field configurations, you can see we Onley have one field configuration. So before we move on, let's create a new field configuration. So I want to come in and let's say we want to make the description required on the bugs issue type. So this field configuration I'm gonna call description acquired field configurations. That's the name click on add. And now that we have this, let's come in. Look for description and let's make the description field a required field. Okay, so what we've done is very similar to what we've done In the previous video. We created a news field configuration, and we made this one field a required field. But as we learned in the previous video, this is going to affect every single issue type if we have it set up that way. So let's create a new scheme tow. Hook this up properly, so I'm gonna come over to the field configuration schemes Page. You can see we don't have any field configuration schemes set up. So I'm gonna click on add field configuration scheme. This is description acquired. Field configuration. There we go again. Gets kind of long. Ah, depends on your naming. Ah, convention, but usually prefer to keep things fairly straightforward. So this is exactly what I'm doing in this field configuration report. Making the description field a required field on bugs issue type is what I want to do. So add that in. All right, so with this scheme, this is what gear is telling us. For all unmapped issue types. It's going to use our default field configuration in the default field configuration. The Description field is an optional field. Let's associate an issue type. We want to say on bug, we want to make the description field required. So we're going to use this field configuration that we set up that has the description field be required when we add that in weaken? See, now the bug issue type is going to use this field configuration, whereas all of the other issue types will use our default field configuration. Now there's one more step we need to take before this will actually happen, and that is to apply this field configuration scheme to the project that we want it toe work him. So let's hop over to projects here. We want this to be in the Web Development team project. And if we scroll down will find our field configuration scheme on the project. Let's switch this. Use a different scheme and select our description required Scheme, associate. And now, by hot back, open up a new tab here. Come in. Creates a new issue just so we can see on the story issue type. You can see description is not required if I switch over to bug the description Field is now a required field. All right, So, to recap, we created a new field configuration. Then we applied that field configuration toe one issue type in our case, the bugs issue type using a field configuration scheme. Then we applied that scheme to a project again. In this case, the Web Development Team project. The end result in our case is that the changes we made in the field configuration again, our case making the description field a required field is on Leah pill Kable for the bugs issue type and Onley in the development of the Web Development Project course. If we wanted that to be in more projects, we could come in and apply the scheme to multiple projects. We can make any sort of changes we want in the field configuration that we want changed the issue type in the field configuration scheme. But that is a look at how field configuration schemes work here inside of Ghira. 30. Module Introduction: in this short module will learn about the issue features injera. Now there's really only a couple of issue features, but we'll take the time to learn what each one is and how they work. Injera as well is what options We have to configure them as Ajira administrator. Before we begin, I would like to offer a reminder that, like every module in this course, while you're obviously welcome toe, watch it from start to finish, you don't have to. In fact, I've designed this module like every other module, in this course to be a collection of videos that you can watch individually toe. Learn what you need as you're setting up Jura on your own, or to simply refer back to you as a refresher from time to time. So no matter which video you choose to watch next, I'll see you there 31. Time Tracking: in this video, we'll take a look at the time tracking feature built into Jiro. So when you hear the term time tracking, you're probably thinking of something a little bit different than what Jiro means. So let's take a look when I hop into the issue administration area and over here under issue features, we have time tracking. We open this up right away, we can enable or disable time tracking. Overall, this is a global on and off switch. Essentially, with time tracking turned on, we need tohave time tracking as a field added to the screen that we want it to be displayed on. So let's take a look at what this would look like. I'm gonna open up a new screen here or a new tab rather, and it doesn't look like I have time tracking on here. So let's find where time tracking is time tracking. It looks like it is not on the default screen. Looks like the default screen is what we're looking at there, so let's edit this real quick. Add in the time tracking field and let's move this up so I don't have to scroll the way down to the bottom so more towards the top. Ah, when we've made this change, we can do a quick re index just so that Jura is happy with the indexing. All right, there we go. All right, so now I close out of this, should be able to switch to a different issue type comeback and all right, so here is the time tracking that we just added in you can see a little bit different than what you're probably thinking of With time tracking. I could have done all that with screens outside of this video because we've looked at screens in a previous module. But little refresher never hurt, so I decided to keep it in. Now, by default. What Jiro refers to his time tracking is this original estimate and remaining estimate. So let's say we want an original estimate of 10 um, a test of the time tracking. And there's some I think description is a required field to. So as we set that up in our field configuration scheme All right, so we set an original estimate of 10. You can see weaken set www, which will be three weeks for D for days. 12 h for hours was gonna put 10. And the remaining estimate, if we don't add something in here, is going to be the same as Theory, Journal estimate, And this will make a little bit more sense here in a little bit. Let's create this issue and then let's open up this issue and we can see over here on the right hand side, we have our time tracking. So this is what you're a is referring to when it's talking about the built in time tracking and then as an end user, I can log my time manually here to burn down the remaining time on the issue. So I originally I estimated 10 and it interpreted that as 10 minutes. I can come in and click on the plus A. I've spent five on it. Add in a work description if I want to, you can see I can adjust automatically, which is going to subtract five from the original estimate of 10. I can set it to a specific amount. If I want to, I can reduce it by a specific amount of I want to. I'm just gonna log this. We can see what change happened. So we can see Originally, I estimated 10 minutes. I've logged five minutes on it, so there's an estimated five minutes remaining. Now, when I typed in 10 what if I didn't really mean 10 minutes? I'm in 10 hours. Well, I could have typed in 10 h in order to indicate 10 hours instead of minutes. But if that's something that we want to be the default as the gear administrator, we can control that over here so you can see all of this time tracking setting. So the default unit for time tracking is minute. So if somebody doesn't enter in the w for week, the D for day, the H for hours, the end for a minute, then it's going to assume you mean minute. Not only that, but if you enter in, let's say if we create a new issue and we enter in one day, how long is one day? What if you work? You enter in one day and then you work for H four hours on that. How much time is left? Well, according to Jura, there are eight working hours in one day, which means if you start off with original estimate of one day one d and you type in four hours is were clogged. That means there will be four hours left on that particular issue. We can change all of that here by editing our global settings. Let's say we want this to be hours instead. Well, can change the hours per day hours per week, exactly the same as what we were just referring to. I'm just gonna change the default unit here to our click on Save once that's changed if I come over here and let's cancel that just to kind of refresh and another time tracking test type in 10 exactly, is what same is what we did before, and the Description field is also required. Probably could have done this on a different issue type, so that wasn't didn't have to type that every time. But all rights create this. And now open this up in a new tab, we can see Jura has assumed 10 hours, which, because there's eight hours in one working day, 10 hours is one day and two hours. Same here with remaining now time logged. If I type in five, you can see five hours is going to be taken away from that. Now we can control how this looks as well. If we want the display format, we can change that however we want. So that's a look at time tracking injera. Now, the last thing I'd like to mention something you might have noticed throughout this course I go back over here, you might have noticed I have this little start timer here Now that is not built in Taji era. That's actually I use 1/3 party tool called toggle T o G L as a time tracker and it has a chrome extension on chrome now and see, this is the chrome extension to allow me to track time for gear up. Of course, that means that the reports are in toggle and not inside of Jura. Unfortunately, there is no built in way toe actually track the amount of time someone is spending on a given issue. Injera. The only time tracking it's built into Jura is what we just looked at. However, there are Adan's that you can do so if you pull this pull this over here can see if you look in the marketplace, which is marketplace that last ian dot com do a search for time tracking. You can see there's quite a few Adan's that allow you to actually add in a more enhanced time tracking capability. I know tempo is a very popular one that you can add in to allow you to track time at in billing, accounting, all that kind of stuff a lot more integrated into Jura course. It is a paid at on and because it to pay that on it is outside the scope of this particular course because I really wanted to focus on just the time tracking and all of the features that are built into Ajira. But I wanted to point that out just in case your team really needs that capability. 32. Issue Linking: in this video, we'll take a look at issue linking injera right. So let's hop into the issue. Administration area Now issue Linking is a way of tying to issues together in a human readable way. So let's start by looking at some of the links that Jiro has by default. Someone come to issue features and go to issue linking and you can see globally. We can turn issue linking on or off by default. It is turned on. We could simply deactivated if we wanted to, and we can see some of these built in links that are there. And really, this is fairly straightforward. It's just a method of organizing your issues. Let's take a look at what this looks like out for end users. Let's come in and let's find any issue. Maybe this guy right here and there's no issues linked to it. So when I click on these three little dots come down toe link and we can tell Jiro. Okay, this issue blocks, let's search for another issue. I don't know one of these bugs here. There we go. So if we link this, you can see now this issue blocks this other issue that we've connected, and you can see the status of that. The priority. You can see if the medium priority you can see the key so you can see that this is actually a bugged the icon. We could open this up to see what it looks like on the other side so you can see this is blocked by this guy right here. It looks like there's another issue that's linked to this as well, so you can kind of get a sense toe how these actually aren't linked together. So there's basically two connections for a link. There's incoming and outgoing, and that's what we can set up here on the back end so you can see this is the link that we used. The outward is blocks inward is blocked by, and you can see that right here blocks and is blocked by. And you could probably guess creating a new one of these is fairly straightforward. Let's say give it a name. So it's a it's a problem and caught the outgoing causes is caused by Ah, you could call this whatever you want, obviously really recommend having it be something that just makes sense add that in as soon as we add that in Now we can come in and on any of these issues. Once again, this is a global thing. So any of those I can link this and either choose the outgoing, which is causes what we set up or the incoming, and it's gonna determine how that is linked there. So like that in find another issue, they would go link those together. And now we can see that link has been added. Really, it's just a nice way of being able to, um, see the issues that are related next to each other and organize those multiple issues that might be related in some way. For example, I found that this is really helpful. When people were reporting bugs, I could keep one bug for the Dev team toe work on. They didn't necessarily have to see all the other dozens and dozens of reports of the same bug. I could actually add a link that it is a duplicate. All of the others are duplicates, so they could see how many times this was reported. But then the benefit there is the end user, which maybe somebody in customer support. Who's actually reporting. All of these bugs can see that all of those bugs are actually being, um they're duplicates of another issue that's currently being worked on, and they could see the status of that issue and be able to report that back to the customers. And again, as with many things here in jail, really less is more so unless you really need to be adding new links, I'd really recommend using the ones that that air here kind of built in by default. But if you do need to add some in now, you know how to do that. All right. And with that, as you can see over here on the left hand side, that's all there is to the issue features section here, injera. So with that, we've come to an end to this very short module. Thanks again for watching, and I'll see you again soon. 33. Module Introduction: in this short module will learn about the issue. Attributes. Injera. No, there aren't a lot of issues attributes, but they could be incredibly helpful to give your team the tools they need toe organize the issues. We'll start by learning how to create statuses. Then we'll learn about resolutions where you see them and how to create them. Finally, will wrap up this module by learning about priorities. Injera. Now, before we begin, I would like to offer a quick reminder that, like every module in this course, while you're obviously welcome toe, watch it from start to finish, you really don't have to. In fact, I designed this module the same as all of the other modules to be a collection of videos that you can watch individually toe, learn what you need, has your setting up Jura on your own or really just as a refresher at any time. So no matter which video you choose to watch next, I'll see you there 34. Statuses: in this video, we'll learn about statuses now. If you watch some of the other videos in this course, specifically the module about work flows, you might already be familiar with statuses. Injera statuses are how issues move through a process or a workflow. So let's hop into the issue administration area. And on the left hand side, we're looking for statuses. It's under issue attributes Now in here, we can see all of these statuses that are global across ARJ era installation. We can see which work flows there associated with. So if I open this up, we can see these are the work flows that are using the open status. Now we're not actually going to be editing. The work flows in the status is area clicking on one of these is going to take us into the workflow area. And again, we cover this in the workflow module how to actually edit work flows and bring statuses in . So if you want to learn that at highly recommend checking out that module, really, all we're doing in this area of the Issues administration section is to manage the status is that we have injera. So let's come in. And actually, you know what? Let's take a look at where these statuses are on an issue, just in case we haven't seen them before. So I'm gonna open up a new issue here. So this guy right here, you can see the status. Okay, So this is what's known as the status law Zinj. And if I hover over this, you can see it says, done issues that are done. So that is the name of these status for scroll down. And that is the description of these status as well. I can click on edit, so change this to whatever I want. So this means Theis, you is done. Whatever description you want there update that. And now if I refresh the page, we'll see if I hover over this. Now the description shows whatever the description of the status is. So that is something that will be seen by end users. We can also come in, create a status if we want. So let's call this on hold issues that are currently waiting for something. Now the category. There's three categories and you cannot add any new categories for status is at least as of this recording. These are built into Ajira. They're pretty much a way of organizing the statuses. So if you notice this is the color green, I switch this to in progress. You'll see it turns yellow. That's because of the category that we can set right here. Okay, that's just so happens to be called in progress and done as well. Um, but we cannot control the categories. However, I would highly recommend staying consistent with those statuses ous far as the categories are concerned. So let's call this one in progress, because if something is on hold, probably already been started, but probably not done so it's in progress. And really a majority of statuses are probably going to be some form of in progress. Some of click on add. We can see our issue that's been added. Our status has been added in here. Looks like I haven't capital owe their someone edit this and fix that. There we go update that now you'll notice that I can actually delete this status. I cant delete any of the other status is. The reason for that is because this status is not being used. It's not in any associated workflow So in order to use a status, we actually have to add it into a workflow. And again, we're not going to cover that in this particular video. We cover that in the work flows module. But I just want to point out that if you have a status in order to delete that status and remove it from Jura, I actually have to remove it from an active workflow. Okay, so to recap, statuses are a key part of work flows. But on this screen here, what we're doing is creating all the status is that we need or managing. All of the status is that we need in our entire Jiro instance, so they can be applied to any workflow. Really? The only thing I haven't touched on here is the order. So if we have statuses, multiple status is used in the same workflow. We can adjust the order that they're displayed here by default. So if we have both resolved and reopened, you know, resolved would be above that, um, again, just really just kind of a visual and organizational manner. We can also translate our status is if we want. So if we have different languages in our gear installation. We can translate all of that. But then, is a look at statuses here, injera. Now, in our next video, we're gonna learn about another issue. Attributes, resolutions. 35. Resolutions: in the last video we learned about statuses in this video would learn about something that's closely tied to statuses resolutions. All right, so let's come into our issue administration area now when you transition an issue toe, a status that's tagged with the done category. If you remember from these statuses lesson, there are categories. If we have one in the done category, we can apply a resolution to it by default. Juror will want to add a resolution to it. It's basically a way of organizing the issues so you can find them later on so you can see some of the default resolutions are fairly straightforward. They can give you an idea of what resolutions are. So if a resolution mean just done, it means the work has been completed on an issue. But what if you dragon issue to the done status, but that for whatever reason, the deaf team or whomever decides that you know what this is actually something we're not going to do when which want to clear it off our board while they can set the resolution is something that we won't do, so it's done. But instead of actually working on it. We've decided for whatever reason, we're not going to do it. Same four duplicate. So you really only need to do the work once. But in the real world, there are a lot of times where issues are reported and there are duplicates of those you can actually do that, Um, and then cannot reproduce is going to be one that's fairly common for bugs and things of that nature. We can always come in and add in a new resolution. So one ad in a new one here just caught me. Actually, this is one that I've actually used before. And when I added in, ah, it was one that my team absolutely loved it very quickly became the very the most common resolution. It was somewhere between. We're not going to do this and done so. It's kind of like me. Morning. Maybe we'll do it, but not right now. Clear it off the board. So adding a resolution of that of men Add that in and they you go now. I did not add a description to it. We could do that if he wanted to. We could change the order again. So if we see all of the different resolutions. You can see the order that those Aaron so move it up. Maybe a little bit above won't do. We can set this as the default if we wanted to. So this would be the default resolution that the drop down box will show on. Well, we can edit this if you want to add in ah, description again. So between I won't do give a little bit more description about that, um, as well as coming in and actually deleting that resolution if we want. Now, if we do set one is the default. Say we set this as the default and we want to change that. You can see it's the default here. We can actually clear the defaults here in the resolution area in order to clear what that default is. So what do these look like for the end user? Well, probably one of the most common areas where the end user is going to do this is on an agile board. So let's pull up in a board here, and if we dragon issue to done it should pop up the screen and it doesn't look like it's doing that So let's come in and actually fix that. So we've covered this before, but a little refresher never hurt, so this would be done on the work flows area. So work flows the deaf story workflow. Let's edit this and AMI transition for Done will select this. Come in to edit and let's show the resolve issues screen say that. Publish. No, I don't need to save a backup published that. And now if I come back to the board, drag this over to done, we'll see this screen. So the default, because we don't have a default, just says Please select. We could select any of these resolutions and really all we're going to do if we select one of these resolutions it done that tags that on there so we can see the resolution for this . We hop into the actual issue. We can see the resolution weaken search for that resolution. So if we wanted to find any issues that are myth, that's the resolution that we have. Ah, we can do that. So really just adds a way of making it easier to find the issues that either actually have been done. We decided for whatever reason you have, you're not going to do them and really helps add that organization to issues before you actually archive them as done. And in the issue administration area. We can manage all of that over here. All right, so that is a look at resolutions here, Injera. Now, in the next video, we're gonna look at another issue attributes called priorities. 36. Priorities: in this video, we're gonna learn about the issue attributes of priorities. So let's hop into the issue administration area over on the left hand side, under issue attributes will find priorities. All right, So, as you can see, these are the default priorities and really injure priorities are exactly what you would think they are, are they are a way of tagging an issue with, well, a priority. So just like statuses and resolutions there, an attributes that get applied to issues. So if we open up an issue just to see what they look like on the front end, we can see the priority here we can change the priority across any of these attributes are these priorities that we've created, and then on the back end, as a juror administrator, we can add, remove or delete any of these priorities. We can also change the order. So if we didn't want highest to be the highest one, that wouldn't make a lot of sense. But just to kind of show. Show this here. Let's say we move it down. Now if I se switch this back and then come in and switch this, you can see highest is no longer, it's no longer the highest. Again. A particular case doesn't really make a lot of sense. But you can see how the order effects, really just the visual appearance of the priorities in that drop down. And just like statuses and resolutions in here, we can add any priorities that we want our issues toe have. So let's say we want to add a new priority of blocker. So this is a priority highest. It's even higher than highest. It is going to block something. And this is something that actually found to be helpful for a lot of clients because everybody thinks that their issues are the highest priority. In a lot of times, you get things marked as the highest priority that aren't really the highest priority. So are deaf. Team can tell when something actually blocks functionality at Major Bug or something like that. So they could add this priority to that to kind of tell that, Yeah, this is actually the high priority. Um, and we can change the icon your oral, so we can either add one in custom weaken, select one. Drag this over here so we can see it. Maybe Add this the blocker icon. We can change the priority color so you can see the color here. Maybe add in. Let's change this to read. You can select from those. It's just a hex color. There we go. Add in our priority. There we go. You probably want to move this all the way up to the top and unfortunately, can't just move this all the way up to the top like you can for options in a field. We have to do this one by one and drag it up. There we go. But now that we have this in, this will show up Soon I refresh the page. We'll see this show up here. There's really no schemes or anything for priorities. They pretty much just show up across all of our Jiro issues. And again, we can edit this. If you want to change the name at a description, Weaken, delete it. If you wanted to do that, we can set it as the default, and we can really, really customize our gear installation with ease. All right, so to recap priorities, injera are something that your team can apply to the issues and then as a juror administrator. You can create whatever priorities your team needs. Now, that brings us to an end of this module where we learned about issue attributes as a general rule of thumb. For any of these, I would recommend Onley adding them on an as needed basis. You can really start to add a lot of confusion to your team. If your team doesn't know what all of these different attributes means. For example, the highest priority makes sense. But will your team know what the blocker priority means? Maybe your DEV team will, but priorities air global so the rest of your team might not. And that might be OK. Maybe you're deaf team Onley. Knowing really means that they're the only ones who will use it. But that's just something to keep in mind. All right, so that is the end of this module. Thanks again for watching, and I'll chat with you again really soon. 37. Module Introduction: and this module will learn about some of the additional schemes. Injera. We'll start by learning about issues, security schemes, which is a way of hiding issues from certain users, rolls or groups. And they're a bit confusing to set up, so we'll take some timeto walk through that entire process. Then we'll look at notification schemes. Notifications are the emails that people get when a new issue is created, assigned to them or any other various event injera with notification schemes we can control when those notifications gets sent out, Finally will wrap up the module by looking at permission schemes, which we can use to give users extra permissions or take away permissions from other users . All of these are schemes that we can apply across all of our projects or on a project by project basis. So we'll look at all of that in this module now before we begin. I would like to mention the same thing that I've mentioned really in every other module introduction. That is that why you are welcome toe watch this module from start to finish. I've designed this module to be a collection of videos that you can watch individually toe . Learn what you need as you're setting up Ghira on your own or simply as a refresher. So no matter which video you choose to watch next, I'll see you there. 38. Issue Security Schemes: in this video, we'll learn about issues, security schemes. So let's hop into the issue administration area over the left hand side of the menu towards the bottom will find issues. Security schemes. Now, if you've seen any of the other videos in this course about schemes, you'll know that that term is something Jerry uses to perform some kind of configuration. That's true here, too, with an issue security scheme. Weaken. Tell Jura to show or hide issues from certain users based on a number of different variables. Now, in this example, I'm going to set up an issue security scheme where we can have customer support, submit an issue, set a security level on that issue so that Onley customer support and administrators can see that issue that way. Say, if somebody from marketing or somebody else won't be able to see that. All right, so here we can see in issue security schemes. There's nothing set up, so that's something else that keep in mind is we have quite a few things to go through. So let's get started. I'm gonna add an issue security scheme, and it's called his customer support security scheme. We can add in a description. If we want. I'm just gonna leave that blank and click on add over here on the right hand side. Once we add this in Ah, there's some fairly straightforward options. Copy, make. A duplicate of the scheme at it would be to edit the name and description of the scheme delete to delete this scheme. What we want to do is add in security levels again if you watch some of the other videos on schemes like workflow schemes inside of workflow schemes, we associate work flows inside of screens. Games we associate screamed Same thing for the security schemes, the issues, security schemes Inside here, we're going to associate security levels. So we need to create some security levels because again, there are none by default. So let's call this customer support. Add a security level. Once we have this security level set up, we need to associate this with users groups and project roles. So to do that, we would add under actions, we can set this as default edit again, going to change the name and description. Delete this security level if you want. I'm gonna click on add in orderto add in here and you can see we have a number of different options available to us for really controlling the security levels and who these air for. So I'm gonna come in and select the group here. I want to set this to the customer support team. Add that in And I also want to add in the administration group and administrators group because I'm currently logged in as an administrator. And so, in order to be able to see this properly and kind of say, we want to see this between the administrators and the customer support, I want to add both of those groups in there. Now I'm just gonna hop into the user management real quick so we can see in the customer support team group because it is a custom group that I've set up. We have to users Emma and Matt. So between those two users as well as anybody in the administrators, which is currently the user, I'm logged in as that's me basically between those three users or anybody else that we add to those groups, that is who is in this security level and who can control the security level now, once we have the security level set up. We need to grant the permission to set issue security on issues. So you can see that's what gear is telling us. Right here. We need to set this permission. Now is a quick side note. If you're not familiar with setting permissions, we will cover permission schemes a little bit later in this module. So if you're watching this module in order from start to finish, we haven't covered that yet, so we will cover that in more depth. I just want to point that out. Let's hop into permission schemes. We only have one the default permission scheme right now. And what we're looking for is set issues security right here. We need to edit this. You can see nobody has permission to set issues. Security. When I edit this will add the administrators grants and also the customer support team. So grant permission to those two groups. And once we have this, you would think we're done. But we have one more thing we need to do. And that is to make sure that we have the security level field set to the screen that we want the issue on. So or that we for the issue that we want to change this on. So let's say let's come in and create an issue. I just want to see that said we want on the bug issue type so you can see it looks like we do not have security level on this screen. So let's see what we need to change. Thesis. A cure ity level is Oh, that's right. We need to actually associate this with the project. So again, because we're doing this all from scratch. We need to come into projects Web development, team down to issue security and associate this scheme one that we just created associate That juror will go through the process of actually associating that security to all of the issues. Acknowledge this, and now we can double check just to make sure on the screens that we have our security level. Yep. We have security level is a field. If you do not have this, you actually need to add in the security level field. Okay, So just to make sure that you have that enabled on the screen, that will allow the users to actually edit the field. So now, if I come in on this bug? Let's say this has security level of customers support. I can set this security level right here and now I have another required field. Just the description. Whatever. I'll type in whatever I want there. All right, so now that I create this issue to me because I'm an administrator and because I set the level I can see this as you know, any other issue, you can see the security level here. I can see this same as any other issue. If I come in, let's say we want to come in. Maybe somebody on marketing. Um, let's say we want to log in as Berry just to see what it would look like for somebody else . Right? So for this issue, I'm gonna copy this slogan is the user and let's paste this in. So we're looking at Dev 34. You can see this issue cannot be viewed because this particular user that I'm logged in as Barre is not a part of either the administrators group or the customer support group. So to recap, using an issue security scheme lets us control which issues are viewed by different users. Rolls groups or more. We need to set up the scheme itself first, then create security levels. After that, we need to associate the scheme with the project before setting the security level. Permissions. We need to make sure to allow the set security level permission and show it on a screen so users can change the security level. Oven issue. It's definitely a process that has quite a few steps. So by all means, if you're stuck at any point, feel free to go back through this video to see how it's done. But it can really be helpful to show or hide issues. For example, I've used this many times to help hide really negative feedback that customer support received from people who were specifically called out until their team leaders had a chance to review it and figure out how they wanted to handle it. Okay, so now that we know about issues, security schemes, in our next video, we'll learn about notification schemes 39. Notification Schemes: in this video, we'll learn about notification schemes. So let's happen to the issue administration area over to notification schemes, which is down towards the bottom. There it is. All right. Now with a notification came, we could control when users will get notified via email when something happens in these schemes are fairly straightforward. But let's take a look at how they work, Injera. So I'm gonna click on this default notification scheme. This is the one that is automatically created for us. And over here, we can, you know, click on notification just the same as clicking on the name. We can copy this to duplicate it. We can edit this to change the name of this if we want or weaken delete this scheme. Um, but since this is the default, we probably don't want to do that. So I would come in and click on this and this is again. This is fairly straightforward. So basically, the event when an issue is created, who's gonna get the notification? The current assign me of whoever the of the issue, the reporter of the issue as well as anybody who is watching the issue and again, fairly straightforward weaken. Delete any of these notifications, We can add a notification if we want. Say, if we wanted to go to a specific user, we could come in and say when the issue is created. That's a sign maybe the current user reporter project lead any of these different things that we want we can add in that notification. So what is one of these notifications look like? Well, let's take a look. So I'm gonna happen to a new window. Let's create an issue. And this, Actually, you know what? This will not creates a notification and I'll show you why here in a second? But it's something important hand. There's a little helper that will help us through with this. Um, that's really helpful as a juror administrator. So I'm gonna sign this to me. And if I create this, if we hop over to the email, we can refresh all we want. We're not going to get this email notification. Why not? Well, let's take a look at Why not? And really in this I wanted to point out this notification helper because this is a great time saver. As a jeer administrator, click on the notification helper. Let's say Okay, this is me. The admin. What's the issue? It waas issue Dev 37. So Dev, 37 Issue created, right Hit. Submit. So why did the notification not go out? Status. This is This is good. I should receive notifications. However, I do not get notifications of my own changes. And believe me, this is a good thing. If you don't really want to get notifications for your own changes, you can learn more about it to go to the jury, help to see why they have this set up this way by default. You can actually customize this under your profile if you want to get notifications. Um, I would really recommend not having that be the case. Otherwise we'll just get notifications of every little change that you do. And you probably don't want that since, you know you're the one making the changes. All right, so now that we know why this notification is not happening, what we need to do to see a notification would be to create an issue from somebody else. From a close out of this, let's hop into the user management here. Let's log in. Is somebody else. Ah, maybe Berry logging is this user. And now if you create an issue, this will create a notification because it's coming from a different user. So I'm gonna sign this back to my administrator, create the issue. Once this is created, I'm gonna switch back to my administrator account. But we can hop into the email and we should see this notification coming. Now, How long it takes to come in is really going to depend on the jury servers and really, how many emails they're sending out? It doesn't send out instantaneously, but it's pretty quick so you can see this Notification came in here and there we go. So we got that notification because an issue was created and I was Theus signing. And that Is this because of this right here. So, in a nutshell, that is how notifications work. You can set up any notifications you wander out to remove them in here to get them set up the way that you want and really recommend using the notification helper to find out why a notification did not happen to fix that. Now what's really cool about this is because it's a scheme we can apply this scheme to specific projects, So I'm gonna come back in. Let's go back to our notification schemes here. Let's create a new notification scheme and let's call this. Maybe no notifications. Turn off notifications. And so, by default, when you create this, there's there's no notifications in here. We could add them if we really wanted to, but I want to show this. So let's come in and let's go to the Web Dev project and let's say our notification change this scheme for this. So I'm gonna use the no notification scheme. And what this means is, any issues created in this project now are not going to create a new notifications, because in the scheme, I have no notifications. However, the other project you can see, I have the feature request project that will create notifications because we hot back to the projects here, feature requests, notifications that is still using the default notification scheme so again so he can see this in action. Let's log in is Barry, and let's create a new Web development issue. This is a test of notifications from the Dev Project, and I'm going to select all copy that just so I don't have to pace it again. Assigned this to me is the administrator, which I have my email open. And I'm also going to create a new issue in the feature request project. And this is from the feature request project. There we go. Oops. I forgot to assign that. That is going to go to me. There we go, a sign that they're all right. So basically, what I've done is I've created two issues, one in the in the Web developed project and one in the feature Request project. And in the Web development project, I have the notification scheme set for no notifications. So we should only get one email notification from this right here. It's not gonna be on create because I forgot to set the assigning when I created it. But when I set the assign e on here, it should still send a notification because here, issue assigned, go to current signings. Right. So this event is you assigned current? Assign me. I should get one notification. Let's go back to my email. Refresh. And there we go. Here is on notification. You notice the feature. It's feature 17. It is not from the Deaf project. We created the issue in the death project first, So if we were getting a notification, we would have gotten that one first. But all we got was the notification from the feature request project. From this issue, we can see the Assign E was changed to me. And that's because this event fired right here and the notification went to the current assigned me, which was me over here in this email. All right, so that is a look at how we can use notification schemes to get a great deal of control over how our team gets notifications across one or more projects. Now, to wrap up this video, I want to highlight this notification helper again. It's here in the project settings. It's also, if we go into our issue administration to notification schemes, we can pop it up, um, on any of our scheme. So maybe I'm this guy here if you want to see why we're not getting something. I've come across this situation a lot with various jeer A administrators that I helped consult for. Someone on their team asks where notification is very often the case with email notifications 99% of the time. It's usually going into their spam folder. But it's hard to say, Has a year administrator. It's hard to say that it's it's their problem, right? You don't really want to say that. So in those instances, this notification helper is great because it helps verify that Ghira is indeed sending out the notification. If there is an issue in the notification is not getting sent out. It tells you what you need to do in order to fix it. But if the notification is sent out, ah, lot of times I will even take a screenshot of the notification helper and send it to that team member toe. Let them know that, as faras Jere is concerned, it is working fine. It's really kind of subtle way of saying, Did you did you really check your spam folder? Okay, so that is a look at notification schemes. Now, in the next video, we'll take a look at permission schemes 40. Permission Schemes: in this video won't learn about permission schemes. All right, so let's hop into the issue administration area on the left hand side towards the bottom will find permission schemes. So with the permission scheme, we can give other people on our team the ability to perform different actions exactly what you would expect from the term permission schemes, especially if you're familiar with how Jura uses the term schemes. Now, is he coming here and you have multiple schemes right away. This is one of the things that Geral will create automatically with a project preset. So, for example, if you create a software project, there might be a default software scheme in here. Now, let's start by looking at what will be doing in this example. So I'm gonna pull over. I have another window here. This is an incognito window and chrome just so I can log in is a different user. So in this window, I'm logged in as Natasha and Natasha is a team leader. So what I would like for Natasha to be able to do is on the Web Development Board. I would like Natasha to be able to create a sprint in order to be able to do that. She has toe have the manage sprints permission on this project. Okay, so let's look at how we can do that. So right now I have the default permission scheme and that is applied to the Web development team. So if I come in here and edit this, add the manage sprints, permission edit who it's granted to have a lot of different options. So either project role application access the group. So I know Natasha's a team leader, so I could add this to the team leader's group that have created Ah, I could come in and really add whatever sort of permission I want, whoever I want. Um, I could add it even to a single user. So if I only want to add it to Natasha, could do that, grant that permission. And now if I come over here, refresh the page. I will be able to create a sprint as Natasha as well has managed to sprint. Ah, part of this rather that it's not just called. Creating a sprint is you can actually complete sprints, um, as well, once that sprint is actually done. So over here, I can complete the sprint as well. But what if I'd like Natasha to be able to manage sprints for the deaf team, but not for any of the other projects. So I have another project in this instance called feature requests, and there is a board associated with feature requests. And right now, if I go into look at that board, Natasha will be able to create a sprint on this board. And I don't really want Natasha to be able to do that. I only want her to be able to create or manage sprints on the Web development board. Well, I can control that here in project permissions. So I'm going to start by removing this permission on the default permission scheme. Come in to edit. I'm sorry. Removed. Remove that single user. I had already added her in there. All right, so she has been removed, which means she does not have permission anymore. So I'm gonna come back to permission schemes. I am. I'm not going to add a new permission scheme. And I'll tell you why I add a new permission scheme, actually. Tell you what I will show. I'll show you so we'll add a new permission scheme. This will be the Web have permission scheme. And I'm I'm gonna end up deleting this, but I'll show you why. So if I add a new permission scheme, you can see there are no permissions granted by default. When you add new permission scheme, you have to start from scratch, which we could do. But that would take quite a bit of time to come through and add all of the permissions that I want. So for the sake of brevity in this video, I'm not going to do that. So I'm gonna come back into my permission schemes, delete this and then copy this default permission scheme and then edit this to be called my Web. Have permission scheme. So this is the Web permission scheme. There we go. All right, So now if I come into this guy here because I copied the default, my permissions are all there from the default. So basically, I'm just taking that I want to add in Natasha to this. So Natasha, there we go. Grant that permission there. Now, in order for this scheme to to be applied to the Web development project, you can see It's not applied toe any projects right now. So I'm gonna come to the Web development team, go to permissions and apply this scheme just like we would for any other scheme. If you've watched any of the other videos about schemes very similar process for applying this scheme. And there we go. So this permission scheme, which has Natasha have the ability to manage sprints, can do that. If we hop over to the feature request project and go into the project settings for this and permissions weaken, see for manage prints here. Natasha does not have that permission. So let's see how this affects her when she logs in. So this is logged in its Natasha. Now you can see up here by refresh this page. This is the feature requests Sprint. I can no longer create a sprint here as Natasha, but if I hop over to my Web development board, I can create a sprint and I can complete the sprint so I can manage sprints on the Web development. But I cannot do it for feature requests. So that is a look at how you can sit up permissions and permission schemes to be associated with a project now. One final thing I would like to say about permissions now because I used a board as an example here on a board I can have, really, it's not required to be in a specific project. So if I edited the filter for this board to show, um, issues that are from the Web development team, then I have multiple issues that are on this board, so that is going to cause an issue, and permissions are all inclusive. So let's take a look at what I mean by that. I'm gonna hop into the development board and let's look at the board settings. Remember, I'm Laugesen Tasha, so she can edit this board. Since she's on here. She is a team leader. And what? I don't have her as permission to do that. So I have not said of that permission for That's fine. Come in. I want to show how to do this here. So in this filter, you can see the filter basically is pulling in tickets from this team as soon as I pulling issues from the feature request team and save this Now if I come to the board and try to actually create a sprint. I cannot do this because now I have both feature requests and Web development tickets, and Natasha on Lee has permission on one of those projects, so that is something to keep in mind. In order to be able to manage a sprint, you have to have permissions to do it for all of the projects there are represented on that board. And I really wanted to point that out because that's something I've come across, probably one of the most common issues with permissions and permission schemes that I've come across both in my own Ah, work as a jeer administrator as well as four administrators that I've I've helped consult as well. All right, So again, that's a look at setting up permissions and permission schemes to be associated with a project. So again, we're in the issue administration and permission schemes setting that up toe work for different projects. And with that, we have come to an end of this module. Thanks again for watching, and I'll chat with you again really soon. 41. Course Conclusion and What's Next: thank you so much for watching this course on issue. Administration injera. I hope you found this course helpful, and I really hope it continues to be helpful as you're setting up your own gear instance or making modifications in the future. Now there's a Thanh of stuff that you can do injera. And because of that, there's really no way to cover every single little link or button as it relates specifically to your project without well being ableto actually get in there and be able to help out with your specific project. The key to successfully setting up Vera is knowing what you want to do. What's the report that you want to see? What sort of things do you need to track once you know that you can then start figuring out a way to get that tow work injera as best as you can, And I really hope that this course helps you achieve that goal with that said. And as with any of my Jerrick horses, feel free to take advantage of the platform here and ask questions. If it's something I can answer without getting in and consulting on your specific project, I'm more than happy to answer them as best as I can. Thanks again for watching, and I hope to chat with you again really soon.