Assigned to Me gadget not showing issues

[Jill Pate]

I created two new statuses (Retest and To QA).

Several issues with that Status are assigned to me, but they do not show in the Assigned to Me gadget.

Did I miss something when I created the new statuses?

[Nic Brough -Adaptavist- · Accepted solution]

I don't think you've missed anything on the status side, but I suspect you'll find that they are "resolved" (i.e. they have a resolution of some sort) and the gadget won't show those.

[Jill Pate]

Yes, they are resolved.

The workflow is that the developer resolves the issue and then send it to Reporter for retesting, then on to QA for review and then close of issue.

That is most unfortunate that this gadget does not show resolved issues that are not Closed.

[Nic Brough -Adaptavist-]

It's never intended to - resolved issues are "done" as far as Jira is concerned.

If that's not how you're using resolution, then forget the "assigned to me" gadget, define a filter that returns what you need and then use the "filter results" gadget instead.

[Shane Kenyon]

I disagree that this is obvious or logical functionality.

Resolved means the developer has handed it off to test. Closed means it is "done".

Its too bad the widget is not configurable because when a testlogs in and sees "no issues assigned to me" they are getting incorrect information.

[Nic Brough -Adaptavist-]

It's not that obvious, I'd agree, as a lot of people here run into it when they're new to Jira.

It IS logical, for two reasons. First, in most cases, "resolved" DOES mean "resolved". Secondly, if that's not working for you, it's not that hard to change it - remove the "resolve issue" screen from transitions into "resolved" and it won't get resolved any more. Obviously, it'll look odd - an issue in "resolved" status showing as "unresolved" in the rest of the system, but the answer to that is "ditch resolved" and have "needs testing" instead.

Personally, I'd actually ditch this approach if I were Atlassian. I'd have a short list of "meta status", which group up individual status within a workflow. (I'd keep the resolution field, just ditch the "if it's set then it's resolved" approach)

[Jemari Thurston]

This really misses the mark. If you are in a tiny .dot com without QA then "Resolved" = "Done" might make sense, but if your workflow defines resolved as a step prior to done (every place I have worked, including two large publically traded companies), then the "assigned to me" gadget ignoring resolved tickets makes no sense.

We have both "Resolved" and "Done" because they are very different. "Resolved" means "Done" TO DEVELOPERS ONLY. If Jira data is meant for consumption by developers only, then this logic is excellent. Hoever, "Resolved" does not mean "Done" to the PO, the scrum master, QA, release/configuration coordinators, other internal business stakeholders, or external customers. The difference between "Resolved" and "Done" in a workflow is important to about 99% of the stakeholders and consumers of a software product. Crafting a gadget around specific job descriptions is dubious.

You can argue anything as 'logical' from a single perspective, but it doesn't mean it will be accepted or logical to the majority. 

[Jemari Thurston]

This really misses the mark. If you are in a tiny .dot com without QA then "Resolved" = "Done" might make sense, but if your workflow defines resolved as a step prior to done (every place I have worked, including two large publically traded companies), then the "assigned to me" gadget ignoring resolved tickets makes no sense.

We have both "Resolved" and "Done" because they are very different. "Resolved" means "Done" TO DEVELOPERS ONLY. If Jira data is meant for consumption by developers only, then this logic is excellent. Hoever, "Resolved" does not mean "Done" to the PO, the scrum master, QA, release/configuration coordinators, other internal business stakeholders, or external customers. The difference between "Resolved" and "Done" in a workflow is important to about 99% of the stakeholders and consumers of a software product. Crafting a gadget around specific job descriptions is dubious.

You can argue anything as 'logical' from a single perspective, but it doesn't mean it will be accepted or logical to the majority. 

[Kevin McNamee]

The 'Resolution' field must be shown in the Field Configuration.

[Nic Brough -Adaptavist-]

Bother, I had a bookmark pointing to a doc on this for v3, but it's gone. I don't know if there's an equivalent page for v5.

[Jill Pate]

Nic, you are right, what you are calling the "system field panels".

They want to easily see what the fix "category" is (like the resolution options) - close to the Resolution field.

[Nic Brough -Adaptavist-]

Do you mean add it to a screen with all the other custom fields, or you mean you want to include it in the system field panels?

Actually, I'm pretty sure you mean the second, which means hacking some code I'm afraid.

[Jill Pate]

I had to change my workflow - ugh.

Created a new field - now I want that field to appear below Status when you open an existing issue. Where do I make that change?

[Jobin Kuruvilla [Adaptavist]]

Are you able to find them by searching in the issue navigator? If not, indexing must be broken.

[Nic Brough -Adaptavist-]

I still think it's the resolution.

[Jill Pate]

Yes, they appear in the Issue Navigator.