nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

I'm prompted to add a resolution on a new issue

Daniel Ceregatti

I do not have resolution set as a configured field, yet whenever I create a new issue in my project and hit the "create" button, the form submission is stopped and a resolution field is added with the only options of "done", "won't fix", or "can't reproduce". This field is also mandatory. I would like for new issues to NOT require this.

I've since created an "Unresolved" resolution which we can pick, but I'd rather this was not required. Thoughts?

Accepted answers

All comments

Nic Brough -Adaptavist-

NO NO NO!

NEVER add a resolution like "unresolved", it's going to break everything.

You need to edit the "create issue" screen and remove the resolution field immediately.

Joe Pitt

You also need to pass the current 'unresolved' issues through a transition that clears the field. The 'unresolved' JIRA initially shows means the field is NULL. By adding ANYTHING to the field it will show as resolved in reports.

Daniel Ceregatti

How about why I'm prompted for this in the first place? I never added this. It seems like a bug.

Daniel Ceregatti

My guess is that resolution is part of a template, but is redundant in my case. I removed the field from the new issue screen and now all is well. Thanks.

Joe Pitt

Whoever setup the screens put it on the screen used for create. JIRA allows a create, edit, and view screen. If they aren't defined the default screen is used. So if you don't have a specific create screen for the issue/project it will use the default screen. It isn't a bug, just the way the application is designed.

Since you're new here is another tip to keep you from falling into a problem that, in my opinion, is a design problem.

Do not delete issues. When you delete it is GONE. Hardly a week goes by without someone wanting to restore an issue. Deleting issues will come back and bite you when it is the most inconvenient. I suggest closing with a resolution value of Deleted anything you want to delete. I implement a special transition only the project lead can execute and it requires filling in a reason field from a select list (such as entered in error, OBE, Duplicate, Other) and explanation text.

. Missing issue numbers will eventually cause a question about what it was and why was it deleted even if it was done properly. Missing data always brings in the question of people hiding something that may have looked bad.

The only viable way to restore an issue is to create a new instance of JIRA and restore a backup that has the issues. Then export them to a csv file and import them to your production instance. You will lose the history.

Nic Brough -Adaptavist-

There are no "templates", and the project setup never adds resolution to any screen. So one of your admins added it at some point!

Daniel Ceregatti

It seems we have dueling admins. I've spoken with my co-worker and we're looking into this now. Yes, I'm obviously new here, and thanks for holding my hand. I feel this has been resolved! PUN INTENDED!

Steven F Behnke

It's an early stumbling block for new admins. Understanding how Status/Resolution should be the very first thing that a new Jira admin understands. They aren't going to make it work any old way -- They MUST respect how resolution is supposed to be used.

Jira gives you plenty of rope to hang yourself in this regard -- It's best to understand what it's for and use it that way ONLY.

Daniel Ceregatti

Right. I'm willing to conform to how things _should_ be done, as long as I'm aware the method is what's accepted. I definitely feel like I've been handed miles of rope, in which I'm finding a myriad ways with which to hang myself. I'm glad the Atlassian community is so responsive and so willing to help. Thanks again!

Joe Pitt

If you want to get JIRA under control you need to treat it like a production system and REQUIRE change control to modify it. Then the changes need to be assigned to one of the admins for implementation. I create a JIRA project with issue types of Add Custom Field, Modify Select List, Modify Screen, Create Project Role, Create Project, etc. Without such control you'll end up with requests for fields you already have from users that don't know it exists and the admin adds the field. JIRA is perfectly happy to create a new field with the same name and type as a current one. This has come up several times in the forum and fixing it is a pain. Everything needs to be documented, no hallway conversations of 'will you...' should be honored if for no other reason you may not remember it the way the requester does.

Allan Hernandez_onw9h5

I confirm removing the Resolution field from the screen (in the case of my project this was not the "create issue" but the "Scrum default issue" and "Bug default issue" screens) solved the problem. I tried editing the "Create" transition so that it cleared the resolution field at the moment of creating an item but that did not work. I just did that to try, I know it's not the right thing to do.

Nic Brough -Adaptavist-

It was the create screen.

Screens can be called anything, it doesn't matter if it was called "scrum default", "bug default issue", or even "not the create screen". The create screen is the screen the project and issue type have been told to use when someone clicks "create issue". It's defined by the issue type screen scheme.

Allan Hernandez_onw9h5

Hi Nic

According to the new Jira issue view, Create issue is the operation not the name of the screen. In turn, it brings the Scrum Default Issue screen.

Screenshot 2021-10-29 153501.jpg

Regardless, I just arrived here from google search and found your answer helpful. Thanks.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Unanswered
Groups
Help

Find more posts tagged with

jira

cloud

jira-cloud