-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Low
-
Component/s: Space - Team Calendar
-
None
-
1
-
Minor
Issue Summary
When a Calendar is configured with Jira Issue Dates → Issue Due Date event and a Date Range, there are 2 issues observed:
- the multi-day range entries display “Issue due: Due X days ago” calculated from Start Date up to the current date (not up to the end date);
- and the popover shows the range under the "Issue Due" context.
Expected: clicking any date in the range should show consistent details and the duration Start Date → End Date, not a relative “Issue due” to today.
Steps to Reproduce
- Create a calendar
- Add Jira Issue Dates event - System Jira, Select “Issue Due Date”
- Add a Jira workitem with Due Date, for instance, on my sample:
Start Date: Dec 29, 2025
Due Date: Jan 12, 2026
- Observe the Calendar - It will show a single entry on Jan 12. Click on the entry will open a window showing:
TEST-33 - test (Due date)
Issue due: Due 9 days ago (today is Jan 21) => Range from the Due Date and the Current Date
Assignee: Unassigned
Status: Done
- Now, edit the event and add a Date Range - observe the description: “You can visualize the duration between two issue dates in Calendars.”
Start Date = “Start Date"
End Date = “Issue Due Date”
Expected Results
- Multiple entries for the workitem added to the calendar, from Dec 29 up to Jan 12
- Select one date from the range, not from the "Due Date" event
- Click the issue should always show the range
TEST-33 - test
Start Date - Due Date: 14 days => Range from the Start Date and the End Date{}
Assignee: Unassigned
Status: Done
Actual Results
- Multiple entries for the workitem added to the calendar, from Dec 29 up to Jan 12
- Select one date from the range, not at the "Due Date" event
- Click the issue does show incorrect label for the value provided
TEST-33 - test
Issue due: Due 23 days ago ==> Issue due is an incorrect label and 23 days ago is the range between Start Date and Current Date
Assignee: Unassigned
Status: Done
Workaround
Currently there is no known workaround for this behavior. A workaround will be added here when available