Why Doesn't statusCategoryChangedDate Match UpdatedDate

[Dave Menconi]

My user used the API to find all the issues closed in June using jql. The call was
https://tripactions.atlassian.net/rest/api/3/search?jql=filter=10568
The filter was
status in (Closed, CLOSED, Done, Resolved) AND statusCategoryChangedDate >= 2019-01-01 AND statusCategoryChangedDate <= 2020-06-28 ORDER BY resolved ASC
(note: he had a “projects in ()” clause but I removed it for brevity and security).

He found several issues that had updated dates that were before his range.
For example X-157 has an updated date of 2020-01-27 and the history shows that it was given a parent (an epic, I assume) on that date but no changes afterward.

He said that all the issues he found were in the X project and the X project is a next gen project.

My theory is that the nextgen project had it’s terminal column moved which would mean that the status category would change. It wouldn’t change the updated date on the issue but would (maybe) change the statusCategoryChangedDate. I admit this is somewhat far fetched but it’s a theory.

Any other ideas?

[Earl McCutcheon]

Hello @Dave Menconi ,

The "updatedDate" JQL feild referance will be any update action issues on the request and  the JQL for "statusCategoryChangedDate" looks at the history of status category change items not the status directly  The Status Catagory will fall into one of the three avaliable categories and indicated by the color of the status.  The categories are  ToDo as Grey, InProgress as Blue, or Done as Green, with the intent to help identify where an issue is in its lifecycle as part  Atlassian's overall visual system. 

Basically whenever an issue is transitioned into a status that has a different status category, the history will be tracked vie "statusCategoryChangedDate".  An example of this would be if a workflow had statuses such as:

• "Open" set to the "ToDo" category
• "InProgress" set to the "inProgress" category
• "in Review" set to the "inProgress" category
• "Done" set to the "done" category
• "Resolved" set to the "done" category

and the statusCategoryChangedDate looks at the status category changed time so if an issue were transitioned from "InProgress" to "In Review" or from "Done" to "Resolved" or even a looping transition from "Done" to "Done" the category will not be changed during these transitions, and would only set a time stamp when going from a status that changes to a new status category.  Any time that the "statusCategoryChangedDate" is changed this is also reflected as a Updated event and would also change the "updatedDate" value,  but if you issued another action such as updating a field or adding a comment the "updatedDate" will be changed again but the "statusCategoryChangedDate" will not be altered in these events causing the deviation in the dates in the two tracking item fields.

So the example you noted of issues being given a parent issues should trigger an update but not a status category change.  The Updated date should be different from the statusCategoryChangedDate if a change was made to the issues that did not include a status change between two statuses that are in different status categories.

If your user is looking for issues that have been updated he should be looking at the JQL "updatedDate" field referance instead. 

Regards,
Earl

[Dave Menconi]

Earl,

Thank you for your thorough explanation. In going through it I realized that I had asked my question incorrectly.  I said the and clause was "statusCategoryChangedDate >= 2019-01-01" and I meant it to be statusCategoryChangedDate >= 20209-06-01"

Allow me to correct (and simplify) my question so I can get it right. The following JQL should never get any issues returned (because the more restricted change date is AFTER the more general). And yet it returns 320 issues:

statusCategoryChangedDate > 2020-06-24 and updated<2020-06-01

I narrowed it down and discovered that the change occurred on the 25th but I can't find anything in the logs. However only ONE project was involved and that project was a Next-Gen project which does not contradict my theory. 

[Earl McCutcheon]

Hello @Dave Menconi ,

Thank you for the clarification, and that is odd behavior for sure and sounds like a Bug as you should not be able to have a more recent statusCategoryChangedDate than the updatedDate.

I played around with this for a bit in a test environment trying to replicate the behavior moving issues around in different ways without any success in replication, so as a next step we want to get you in touch with our Support team so they can take a look at the data and issue history of the affected project in the instance directly to try and find where the disconnect occurred.

I created the following Support request on your behalf, please go to the request for next steps and let me know if you are having any issues logging into the support portal.

• https://getsupport.atlassian.com/servicedesk/customer/portal/42/PSCLOUD-50026

Regards,
Earl