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; } } }

How to close issues that are caused by other products?

Sorin Sbarnea (

Assume that you got an issue that proves to be valid but that cannot be fixed until an external vendor will fix an existing bug.

Keeping the bug open will clutter the bugs making harder to deal with things where you can do something about.

Assuming that you areare already a watcher on the external bug, how we should close this bug?

I am concerned about what Resolution should be givven to an issue like this.

The default set of resolutions that not seem to have something that make sense.

Still, behcause Resolutions are shared across all jira projects and there is no way to filter them by project, we need to be very carefull about adding new types of Resolutions, as they would have to make sense and not cause confusion.

Accepted answers

All comments

Timothy

I am concerned about what Resolution name should be given to an issue like this.

Well, you do not really resolve an issue that is not fixed. What I would suggest is to create a new status in your workflow (e.g. Pending External) to park the issues under.

Sorin Sbarnea (

Let me put it this way, I already have a Parking state, but this makes sense only for things that are going to be fixed in the foreseable future. For things that are outside your control, parking doesn't make sense, also putting these here will make it harder to triage the parking.

Also, "WontFix" is not appropiate because it indicates that: "we do not want to fix it", not that "we cannot fix it, but we would like to".

I am considering an "External" Resolution, with the meaning of not fixed due to external cause.

The name has to be short and without spaces, in order to ease the JQL creation.

It is a comon misunderstanding that having a Resolution means a fixed status. Having a Resolution means that you do not expect this to change in the future. That's why we have things like Fixed, WontFix, Invalid, Duplicate,...

Norman Abramovitz

You can add new resolutions and each project could have different resoltuions. We added a new resolution NOT-FIXED-DEPENDENCY and then resolve it. We do not close. It sits in this state until the dependency is resolved and then we clear resolution and sent it back to the previous state. For me, this makes more sense than using a state because you made a determination and the issue cannot be fixed by you until something else happens.

We also link the two issues together and mark the link as a blocker when that is possible.

Of course if you are never going to fix it then close.

Sorin Sbarnea (

I guess you had the same case as me. Two remarks, "not-fixed-dependency" is too long and that Resolutions are global per Jira instance, at least in 5.x and as far as I know Atlassian did nothing in the direction of fixing this an making them configurable per-project basis. Now, I start to think that maybe "Blocked" could be an alternative to "External", solving issues as "Blocked" could make sense in this case. In case somebody wonders, I am referring to permanent-like blocks, where you do not expect this to change less than 1-2 years (like many Jira bugs....). Usually I would use WontFix but I do not want because it gives a negative message (that you do not want to fix). ... or just CantFix

Nic Brough -Adaptavist-

I think this is mostly in the language and process

Timothy's point about the workflow status is right - you really do need a status like "parked" or "blocked".

Some places I've worked have solved this with two such status "blocked internally" and "blocked by external". This is where your process kicks in - sometimes they are both treated as unresolved, sometimes only one is unresolved and sometimes both are resolved. That's determined by process and how users want to report on this stuff

Other places have a single "blocked" and leave them open because they need to be dealt with however they are being blocked. That's where a resolution can become quite useful because you still might want to remove them from reporting.

Another helpful thing to do, whether you use resolution or not, is to encourage your users to use labels, or even dedicated field to say "blocked by external party". One workflow I've got here has a screen in the workflow that offers the users a list of reasons why an issue is blocked when they push it into the blocked status. One option is "external party"...

If you are going to "resolve" any blocked issues, then I would say that it's well worth having a very clear resolution for "blocked by external issues" type status, and that's where the language thing becomes important. For me, it's actually quite hard to form an English resolution phrase that's short enough not to look silly or get truncated by Jira, and yet clear enough to say "we've got this one closed because we can't do anything about it because we are relying on an external process/organisation". The one I've got at the moment really is "blocked by external" - I don't see any value in limiting it to one word.

I'm not sure there is a misunderstanding that "resolution = something" has a fixed status. Sometimes it does, sometimes it doesn't. It depends on how a team works and reports more than anything.

Norman Abramovitz

I am confused by your comment that it needs to be short beause of JQL though.

Norman Abramovitz

We also do not use a state because all states are parking states.

Norman Abramovitz

We have unique resolutions per project. It might be per issue type since our documentation issue type have different resolutions from out source code based resolutions. We had this change since 4.4.

I did a quick search and found this jira support issue.

https://jira.atlassian.com/browse/JRA-3821

Did some more digging and we are using custom fields.

Welcome!

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

Quick Links

Find more posts tagged with

jira

jira-administration