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

Resolution date isn't set

Jaison Reis

I've found a bug while trying to create a issue report. My issues are marked as resolved, but the resolution date isn't set. In my mind the expected behavior of this field is that when I change de resolution from unresolved to fixed, it will change the resolution date too, but it doesn't.

Am I doing something wrong or this isn't really the expected behavior? If i'm doing something wrong, how can I update the resolution date field to reflects the actual resolution date of an issue?

I already have contacted the Atlassian about it, but they told me to find help with the comunity, by the answers website (this one).

Accepted answers

All comments

Timothy

Not sure if a re-index will work but give it a go.

I already have contacted the Atlassian about it, but they told me to find help with the comunity, by the answers website (this one).

If they told you this (and not helping you), they are not doing their job.

Vidic Florjan

>> when I change de resolution from unresolved to fixed, it will change the resolution date too, but it doesn't.

Which event is fired in postfunctions of the Resolve Issue transiton: "Generic" or "Issue Resolved"?

Should be: Fire a Issue Resolved event that can be processed by the listeners.

Natalie Hobson

Did you ensure that the Resolved field is in your view screen, and not hidden in your field configuration?

Natalie Hobson

Actually no, the date is based off the field being changed from Unresolved to having any resolution value. The "Issue Resolved" is just for notifications.

Jaison Reis

Thank you everybody. I appreciate your effort giving me an answer.

Which event is fired in postfunctions of the Resolve Issue transiton: "Generic" or "Issue Resolved"?

Actually, I really don't know about it. I'm using default in this one, I don't remember to change these postfunctions. The Issue Resolved action will trigger a internal postfunction to change my resolution date? If it is like this, why some issues have their resolution date updated and others don't?

If they told you this (and not helping you), they are not doing their job.

After I've posted this answer, I found an issue tracker and ask the same question there. I'm justing waiting for a solution there for my problem now but I really appreciate the answers here.

Did you ensure that the Resolved field is in your view screen, and not hidden in your field configuration?

Yes, I'm seeing the resolved field. I tryed to change from fixed to unresolved and see what happens, then change to won't fix or fixed again to see if the resolution date is updated, but it doesn't.

Again, thank you all very much for the answers. According to the JIRA team, they didn't found any issues with this scenario, an answer that am suprised to get, but I'll still trying there to get a solution.

Vidic Florjan

Yes, formulation of the comment was not good enough. I want to find out possible (and almost impossible) causes of the problem. It is also possible that event is somehow connected with listener, permissions, ... So it is possible that different events ("Issue Resolved" / "Generic") causes different behavior of the system ...

As Jaison said ("I don't remember to change these postfunctions") this is not the case here.

Another sugestion:

You can go through history of the issues and try to find out the differences between issues with and without resolution date.

Nic Brough -Adaptavist-

No, I think the event thing is a complete red herring. Please forget that.

Logic: Events are for triggering associated actions (mostly sending email). They are NOT for triggering recalculation of any derived or calculated fields, indexing or otherwise keeping an issue up-to-date. If you want evidence - I've got workflows here that never fire "issue resolved" and have resolution dates that work perfectly.

You've checked my next thought about field configurations and so-on, but I doubted that was a problem too. However, could you just check that you have NOT got "resolution date" as a custom field?

In your original question, you say "on creating issue" - can you confirm that you're seeing the problem on transitions other than "create" as well as on create?

And finally, does your log say anything at all when you're going through a transition that fails to update the resolution date?

Nadir MEZIANI

Hi,

I think that you can do it like this.

1. Create/edit your transition. In the field, either select or choose a screen that does not 'Transition View' 'No View For Transition' contain the field (e.g. the screen). 'Resolution' 'Add Comment And Assign'
2.Add a new post function of type . Select from the select list and select a suitable 'Update Issue Field' 'Resolution' 'Issue Field' resolution from the select list. 'Field Value'

Goog luck

Nic Brough -Adaptavist-

I think the point of this question is that Jira is supposed to be doing this for us, automatically. It certainly does on my installations, no messing around with post functions (I also suspect that any post function you find will explicitly ignore resolution date, because it's a system field)

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud