Set the status of an issue while creating it

[#1]

Hello Community

I’m Luke Ellery and I work as a content designer on Jira Software.

We’ve noticed a lot of our users change an issue’s status right after they create it. So we’re adding a new field to the Create issue window, letting you set the issue’s status when you create it. For example, select In progress if you’ve already started the work.

We’re rolling this feature out slowly while we gather feedback to help us improve the experience, so you might not see it in your project straight away.

How the status field works

While you’re creating an issue, you’ll see a field labelled Status. Select it to see a list of available statuses to choose from. You’ll only see statuses that:

• you have permission to use

• don’t have any special triggers or conditions associated with them in your workflow

• can be transitioned to from the To do status

You’ll always see the initial status or transition in your workflow. Normally that status would be To do, but if you’ve made a custom initial status or transition in your project, it will always show.

Select the status you’d like your issue to be in when it’s created, then continue creating your issue as normal. When you hit Create, the issue will automatically transition into your chosen status.

Managing the status field

If you find this global field is competing with any automation you’ve set up relating to issue creation, you may need to disable the field which will completely remove it from the Create issue window.

1. Go to Settings > System.

2. Select Edit Settings.

3. Scroll to Options and choose the settings you’d like to turn on or off.

4. Select Update to save your changes.

Troubleshooting steps

We've noticed a few questions asking why specific statuses aren’t showing, so we've added these steps to help you find out more.

Company-managed Project

1. Open the workflow editor by going to Project settings > Workflows > Edit (pencil icon). Alternatively, open an issue > select the Status field and then select View workflow.

2. Make sure you're viewing the workflow as a Diagram. Pick the status you're expecting to see in the Create issue window.

3. Check if that status has a global transition (an arrow from "All" to the status).
   This is required for a status to appear in the Create Issue window.

4. If it does have a global transition, select the arrow from "All" to the status. That will open a small transition window. Check that there are no triggers, conditions, or validators. If any of these are set on a transition it will not appear in Create Issue.

5. Select Properties in the transition window. Do any of the listed properties start with jira.permission? If so, you might not have permission to use this transition.

6. Back in the transition window, select Edit  to check for Screens. If a screen is selected the transition will not appear in Create Issue.

Team-managed Project

1. Open the workflow editor by going to Project settings > Issue types > Edit workflow. Alternatively, open an issue, select the Status field and select View workflow.

2. Pick the status you're expecting to see in the Create issue window.

3. Check if that status has a global transition (an arrow from "Any status" to the status). This is required for a status to appear in the Create Issue window.

4. If it does have a global transition, select the arrow from "Any status" to the status, and a sidebar will appear titled Transition.

5. Check that there are no rules listed. Some types of rules prevent a transition from appearing in Create Issue.

6. Select Properties in the transition sidebar. Do any of the listed properties start with jira.permission? If so, you might not have permission to use this transition.

Permissions

In both types of projects there are permissions that can prevent a status appearing in the Create Issue window. Jira has a very fine-grained permission structure, so the best way to test this is to create an issue and try to transition it to the status you want. If this works, then permissions are not stopping the status appearing in the Issue Create list.

If you have any immediate thoughts or questions, you can share it in the comment thread below

Thanks for reading,
Luke

[Alex Koxaras -Relational-]

Hi @Luke Ellery and thank you for the information!

On a first glimpse this could be a useful feature for certain users! I've checked on two instances on mine, but can't seem to find it yet. So I'll wait till it's deployed.

Quick questions:

1. Will this be available for TM projects as well as for JWM, under the same rules and conditions?
2. What exactly are we going to disable from the settings? This exact feature so that the users will not be able to choose a desirable status upon creation? So this status field isn't going to be placed on the create screen?

[Marin Varvodic]

Hi Luke, nice extension to the main Jira functionality. Great work!

[Manon Soubies-Camy]

Hi @Luke Ellery, interesting feature! Would like to hide this field when only one status is available though :)

I looked at the System settings but couldn't find the option to disable it. Is it already deployed on all Jira Cloud sites? Also, do you plan on making it a project option instead of a global one?

[Luke Ellery]

Hey @Alex Koxaras -Relational- thanks for commenting!
It's still rolling out, could take a few weeks to pop up on your instance. We're just trying to give people plenty of notice. To answer your questions:

1. It's Jira Software only, so it will be available in team-managed projects but it won't be available in Jira Work Management (at least not yet).

2. In Project settings, you can completely disable the field. Essentially, you can toggle the feature ON or OFF and when it's OFF, it'll be like it was never there at all. Statuses will act as they always have and users can still edit the status after creation. Disabling the feature simply removes the option from the Create issue screen.

[Luke Ellery]

Hey @Manon Soubies-Camy, thanks for commenting. It's still rolling out so there is a good chance it won't be in your instance yet, give it a few weeks and then hopefully you can start making use of it.

It will only be available on Jira Software, not across all Jira products.

You can't set rules for when the field is hidden, you'll only be able to manually hide the field by disabling it in System settings. Please note, doing so will disable it across all projects in your instance.

Once the field is showing in your instance, the functionality to disable it will also be available to you. It's a goal of ours to give admins more control at a project level, but that functionality isn't available as part of this release.

[Alex Koxaras -Relational-]

@Luke Ellery thank you for the clarification!

[ihe]

Hi Luke

You wrote the following in December:

In Project settings, you can completely disable the field. Essentially, you can toggle the feature ON or OFF and when it's OFF, it'll be like it was never there at all. Statuses will act as they always have and users can still edit the status after creation. Disabling the feature simply removes the option from the Create issue screen.

I cannot find a feature to toggle this off anywhere? I am in a company managed project and the functionality has been rolled out to us. But I want to remove this! Please help

[Luke Ellery]

Hey @ihe happy to help!

First thing to call out is you need to be an admin to turn the feature off. 

The process to switch the field off is: 

1. Go to Settings > System 

2. Select Edit settings 

3. Scroll down the page until you reach a section titled Options

4. There will be an option called Status, check the OFF box.

Then you should be all good. Let me know if you run into any problems. 

[NiYunfan]

Good feature!

But why make it a default enabled feature with product-wide global on/off setting? Please turn it off as default and let user enable it if they want. Also, make it a project-wide setting, please!

Another question: on most of our jira projects, we see no available select item, but seeing: You don't have permission to transition the issue. Why? How can we use that? Is this feature limited to workflows with ALL-->SomeStatus transitions?

[조은성]

Suddenly, when creating an issue, the Status Value field was exposed.
I searched in a hurry and proceeded with the off setting method on the page.
Currently, it is not exposed normally. Thank you.

[Samantha Gardiner]

Looks like we received this update overnight. I am having a problem though. We have a custom initial step called "Requirements Gathering" that is set to the default status of new issues. However, I cannot change the status to anything. It says "There are no statuses available for you to use". 

Any ideas on what I need to do to fix this?

[Jordan McCombs]

I love the idea behind this, but I really don't like that once this is enabled it shows up on all create screens across the board. We need to be able to customize which projects can and can't do this on creation.

We have over 600 projects and 2 million issues in our instance, having this enabled is going to cause so many users to ask what this is, why they can't change the status to what they want, etc. I think that out of all of our users, a very small % of users will make use of this functionality. The ones that do will make great use of it, and this is a great tool for them. But I fear this is going to cause a lot of headache as an Admin as it stands today. 

Update: We've gone ahead and disabled this in our instance until it can be enabled on a project by project basis. 

[Luke Ellery]

Hey @NiYunfan we turned it on by default because we saw a lot of potential in the value it would bring to people and we didn't want anyone to miss out and never know it existed.

We did however want to make it very easy to switch off because we know changes like this can sometimes cause problems. We will explore making this option more configurable and project specific.

If you'd like more options to appear in this field while you're creating an issue, then you'll need to edit the workflow so that the statuses you'd like to see don’t have any special triggers or conditions associated with them. We don't want to break or skip steps in your workflow, so the statuses that appear here are only ones that are possible within any limitations set by a workflow.

[Luke Ellery]

Hey @Samantha Gardiner, we've built this feature to work within any limitations that are set by a project's workflows.

If your workflow states that an issue must start with the status "requirements gathering", then we only show that status so as to not break/skip steps in your workflow.

If you'd like more options to appear in this field while you're creating an issue, then you'll need to edit the workflow so that the statuses you'd like to see don’t have any special triggers or conditions associated with them.

[Luke Ellery]

Hey @Jordan McCombs this is really useful feedback, so thank you for sharing.

We've tried to build it in a way that reflects how people edit statuses after issues have been created. The same fields and functionality should be available to most people when creating an issue and when editing it.

However, I understand custom statuses and workflows can make it more complex and it results in some people being met with blockers. We'll explore making this feature project specific and more configurable to help alleviate this.

In the meantime, if it is causing more problems than it's worth in your instance, you can switch the feature off via Settings > System

[Haddon Fisher]

Hi @Luke Ellery. I think I would agree that this is an intellectually nice feature to have. There are teams whose workflows might make it nice to put issues directly into a status, and a saved click is a saved click.

That being said, execution needs a lot of work.

1. This is already called out but there's just as much use-case for this in JWM as there is in JS, if not more. The level of differentiation between the two is already a big problem (still true, if less so, for JSM) so please stop adding to the mess.
2. Also called out above, but enabling this by default is the opposite of "being respectful of production systems". I totally get you want people to know about it and that this is a Cloud platform we have zero control over, but 'enabling everything by default' is not a scalable announcement strategy in the first place. If you need to make the features more discoverable, focus on that. If people aren't picking up what you put out...that would be a different problem :). 
3. Speaking of enabling, +1 to not making this a system-wide default, but per-project. This feature could never apply to all teams, so having it an all-or-nothing negates it's usefulness pretty much entirely.
4. It feels like this skipped a UX review. There's already two ways we control screens: the actual "screens" functionality and the newer "layouts". Adding a third is the wrong direction. This could have just as easily been enabled by adding the "Status" field to the 'create' screen.

[Santiago Gonzalez Souto (inetum)]

Hi @Luke Ellery . I also think that it has not been the best way to deploy this new option and that it may be interesting for certain work teams. But making it available in corporate management environments has been more annoying than effective.
As @Haddon Fisher says:

• "Not making this a system-wide default, but per-project. This feature could never apply to all teams, so having it an all-or-nothing negates it's usefulness pretty much entirely."
• "This could have just as easily been enabled by adding the "Status" field to the 'create' screen."

[Marvin S]

This shouldn't be a system setting, it should be a field that you can control at the issuetype level

[Jack Brickey]

prefer Status be OFF by default.

[Chris Austin]

The set of status values is surprising for my projects.

New issues start with "Needs Triage" in our workflow, and based on the description I'd expect to see "Needs Triage" along with any statuses that are reachable from "Needs Triage", or possibly from "To Do" if that piece is hardcoded.

When creating an issue I see these options:

* Needs Triage

* Duplicate

* Rejected

* Code Review Requested

* Pull Request Merged

This is surprising since from Needs Triage I have transitions to:

* To Do

* Short Term Backlog

* Long Term Backlog

* In Progress

* Blocked

* Done

* Duplicate

* Rejected

* Code Review Requested

* Pull Request Merrged

The transitions from To Do are similar, except it has one to Needs Triage.

The most surprising absences are "To Do" and "In Progress" - there are no conditions/validators on these transitions, so it seems to be misbehaving.

[Luke Ellery]

Hey @Chris Austin, thanks for reporting this. It could be a bug. I'll speak to the team to try understand what's going on for you. 

[Luke Ellery]

Hey @Haddon Fisher, thanks for the feedback. I've taken it back to the team and we're exploring some of the things you've raised (a few of those things have been raised by others in the comment thread too). I'll update the article when I have more information to share about it and we'll continue monitoring feedback in the meantime.

[NiYunfan]

It seems if there's screen configured in workflow transition to some STATUS, that STATUS won't appear.

[Luke Ellery]

Hey @NiYunfan, I've spoken to the team and I can confirm that this is correct.

The reason they won't appear is that we don't know what the screens will do.

In some cases, they could be very important to show, so we don't want to skip them by allowing someone to transition automatically. Any transition with complicating factors, we don't show in the list. Complicating factors are things like screens, post-functions, validators, triggers or rules.

[Luke Ellery]

Hey @Chris Austin, I've spoken to the team and it seems this is not a bug, it's an error in the community post which I will update shortly. I wrote this:"

You’ll only see statuses that:

• you have permission to use
• don’t have any special triggers or conditions associated with them in your workflow
• can be transitioned to from the To do status"
  
  

The last point isn't necessarily accurate...

We show a status in the list if there is a transition into that status that meets these conditions:

• It is initial (initial transitions are always allowed in the list, even if they have complicating factors, because the only complicating factors you can add to initial transitions have been tested to work)

OR

• It is global AND does not have any screens, post-functions, validators, triggers or rules
  
  So in this case "To do" probably doesn't have a global transition (because you have "Needs Triage" first). The reasoning behind this is that wanted to avoid causing problems for people by letting users skip around statuses that could be important. Let me know if you have any other questions. Again, thanks so much for raising it.