When the "Days in column" setting is enabled, an incorrect number of dots is displayed in the Sprint cards
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
This KB article lists a few scenarios where an incorrect number of dots is displayed in the Sprint Cards, when the option Days in column is enabled for a board in Board > Configuration > Columns:

The 2 scenarios that have been identified so far are listed below:
Scenario 1
The number of dots is higher than the expected number (for example: the number of dots shows 20 days in a card, even though the issue has just been transitioned to the status for the very first time):


Scenario 2
The number of dots is showing a huge number of days (for example: around 19k days!):

Environment
Jira Server/Data Center 7.0.0 and any higher version.
Diagnosis
Diagnosis for Scenario 1
Take a look at the post-functions associated to the transition going into the status in the column where you see that the number of dots is incorrect, and check if you see both post-functions listed below:
1 post function showing a class name:
1 2
Type: class Class: com.atlassian.jira.workflow.function.issue.UpdateIssueStatusFunction
1 post function showing a "user friendly" name:
1
Set issue status to the linked status of the destination workflow step.
If both post-functions are present in the same transition, then this KB article is relevant, and you can proceed to the sections Root Cause for Scenario 1 and Solution for Scenario 1.
Note that both post-functions are referring to the exact same post-function. The only difference is that, in one case, its class name is showing, or in the other case, its user-friendly name is showing.
Diagnosis for Scenario 2
Take a look at the post-functions associated with the transition going into the status in the column where you see that the number of dots is incorrect, and check if you can find the post function that is meant to update the issue history. Please note that, depending on some circumstances, this post-function might be showing in the UI:
as its class name:
1 2
Type: class Class: com.atlassian.jira.workflow.function.issue.GenerateChangeHistoryFunction
or its "user friendly" name:
1
Update change history for an issue and store the issue in the database.
Please keep in mind that both names refer to the exact same post-function.
If this post-function is missing from the transition, then this KB article is relevant, and you can proceed to the sections Root Cause for Scenario 2 and Solution for Scenario 2.
Cause
Root Cause for Scenario 1
The transition contains duplicate post-functions that set the status twice during the transition, which can be seen in the issue history, and which causes some issue history corruption:

Because the data related to the issue history is corrupted, the issue card in the Sprint view shows an incorrect number of dots.
Root Cause for Scenario 2
The transition is missing the post-function that is supposed to update the issue history whenever the issue transitions to a new status.
Because the data related to the issue history is missing for the issue, the card in the Sprint view incorrectly assumes that the issue was transitioned to the new status at the Epoch/Unix timestamp "0." Since this timestamp corresponds to the date "Thursday, January 1, 1970 12:00:00 AM," which was more than 19k days ago, the card shows more than 19k dots.
Solution
Solution for Scenario 1
Remove the duplicate post-function from the transition by removing the one that shows the class name com.atlassian.jira.workflow.function.issue.UpdateIssueStatusFunction, as shown in the screenshot below:

Make sure to publish the workflow after you make this change.
Solution for Scenario 2
Add to the transition the post-function which updates the issue history by:
Clicking on the link Add post function
Selecting the post-function listed as Generate Change History - Updates change history for an issue and stores the issue to the database.
Clicking on the Add button
Publishing the workflow
Was this helpful?