Establish why they're not appearing first. Find an issue that you think should appear, and check
If it matches both of those, then we may need to dig further.
Er, we're not support, we're a community of users who try to help each other.
It sounds to me like your indexing is not functioning, but that would be very unusual for OnDemand (because you can't really install anything that might be breaking it)
Could you confirm if you are using OnDemand or your own installation?
I used a corporate JIRA system at my last company and when I started my new job at a small company I found that they had no issue tracking system. A member of upper managment had been pushing for it and suggested JIRA OnDemand. I ended up being the administrator even though I am a hardware verification person. I have set everything up so I know everything about our setup
I figured it out. It is due to the resolution bug that exists in OnDemand. I could not modify that field at all. I was told it was a bug and as a result a JIRA support person forced a change to make it so i could. After that I created a new resolution called undetermined which is what all my open issues are set to.
That doesn't sound like a bug to me, it sounds like you have set up resolution incorrectly.
The whole of Jira assumes that if you have a resolution set to ANYTHING AT ALL, then the issue is RESOLVED and hence will NOT appear in "assigned to me".
If you add a resolution called "undetermined" (or "unresolved"), then you are telling Jira that the issue is RESOLVED becuase there is something in the field.
You should immediately remove this "undetermined" resolution. The resolution field MUST be left empty for Jira to see the issue as unresolved.
It's not required, it's defaulted because it's supposed to be used later in the workflow.
You must remove the field from the create screen you added it to, and delete any spurious resolutions. from the list because they are breaking your system.
(Sorry, I failed to answer your question about filters - the answer there is "you need to rewrite the whole of Jira's handling of the resolution field". OR just configure it correctly)
As you have OnDemand, you have access to support. They may be willing to talk to you direct, but I've not tried it.
The resolution for these issues is quite clear though - you should use Jira as it's been designed and built, with an understanding of how it works. Remove the resolution field from all edit screens except those used on a resolve/close transition, and then delete the resolution options that are breaking Jira for you.
How it's been designed and why it does it that way is a different conversation (I believe the way the resolution field affects the open/closed state of an issue is very weak. It's certainly not intuitive, as you can see it's lead you in completely the wrong direction and broken your setup)
Originally I had no way of defining the resolution state when I closed the issue so I submitted a ticket and they told me it was a bug. As a workaround they changed my database in some way so I could do it. The result was that I had to give a resolution with every state change. I complained about that and they said there was nothing they could do. Now I am stuck
I don't quite understand what that means.
Resolution is a field on an issue, which draws its possible values from a list. It doesn't belong to a "state" (and I'm not even sure what you mean by state, although I'm guessing it's "status"?)
You have accidentally configured Jira to set it when you didn't intend to, and also added a value to the list that you don't actually want to use.
To prevent more bad data being put in, you need to remove the field from all the screens that let you set it, EXCEPT the screens which are on the transitions that go into a resolved or closed status.
To fix your existing data, first delete the problem entries from the list ("undetermined" and any others you've added that are supposed to mean "unresolved"). The difficult bit is going to be undoing the damage to issues that you've got other resolutions that you still need on them, but are still "open". These will gradually drift into being correct if you do nothing because you'll working on getting them to a closed status anyway.
To clarify what was done in your support ticket - you wanted to configure resolution on a ticket but could not because it was not on your default screen. This was not a bug, the support engineer simply added it to that screen for you.
Additionally, you wanted to determine whether or not the resolution showed on a screen based on a workflow status, which is not possible or how that works.
Hopefully that makes a bit more sense!
I guess we are going in circles. Then I change states (for example from open to confirmed) it forces we to enter a resolution. Fixed was the default so I added undetermined because none of the resolutions available were applicable at that point. I tried to modify the configuration so I did not have to define a resolution till the closed state and it would not let me. I am forced to pick a resolution!!
I do understand why you think you're going in circles, and I think there's one thing missing from what we've said above, but you are close.
You need to do what I've said above, to repeat it
Hey Community mates! Claire here from the Software Product Marketing team. We all know software development changes rapidly, and it's often tough to keep up. But from our research, we've found the h...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs