View Issue Details

IDProjectCategoryView StatusLast Update
0025742mantisbtotherpublic2019-06-14 02:39
Reporterbigjason Assigned Tocproensa  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version2.21.0 
Target Version2.21.1Fixed in Version2.21.1 
Summary0025742: Summary "By Date (days)" gets wrong number
Description

The errors are:

  1. days 2 ~ 90 didn't include the issues in days 1, but days 180 & 365 include the issues in days 1.
  2. the Opened number at days 180 & 365 is more than the actual issues number.
    Like the figure,days 180 has 7 Opened, but click the link to view,there only have 5 issues.
    The days 365 has a larger number of differences.

The number that Opened and Resolved is very different from the 2.19 version.

TagsNo tags attached.
Attached Files
scrcap-2019_5_8-00700.jpg (33,553 bytes)   
scrcap-2019_5_8-00700.jpg (33,553 bytes)   

Activities

cproensa

cproensa

2019-05-08 10:17

developer   ~0062038

Last edited: 2019-05-08 10:18

days 2 ~ 90 didn't include the issues in days 1, but days 180 & 365 include the issues in days 1.

The rows with 0 count in that date range are not being included in the added count.
Fix: https://github.com/mantisbt/mantisbt/pull/1510

the Opened number at days 180 & 365 is more than the actual issues number.
...very different from the 2.19 version.

This count has been slightly redefined, as part of the changes for summary page released with 2.20.
See:
https://github.com/mantisbt/mantisbt/commit/64ee622678c2ab3f164b7accfead84967e93de42

I think that now, at least, is more consistent.

 Redefine summary open, resolved, by dates

Previuos summary section "by dates" has two problems:

1. The criteria for "opened" issues, is by submit date. But the criteria
for "resolved" is based on history log for transition, from unresolved,
into resolved status. The main reason is that we don't have a specific
resolution date.
If having issues with succesive resolve and reopen transitions, and
those history records fall between different day ranges, the balance
result can be incorrect.

2. The queries for history table are considerably slow, and there is a
query for each day range. It all adds to the summary page response time.

The change here consist of:
- Using the same criteria for opened issues, where every new issue, or
  reopen, history log counts for the total.
- Every open or resolve transition, for a given issue, is counted
  separately.
This way we get a more accurate balance indicator, and ideally, for
every new/reopen action, we should have a resolution action.

Additionally, after this change in criteria, the history data can be
aggregated and extracted with one query for all date ranges, thus
greatly improving the performance issues.

Like the figure,days 180 has 7 Opened, but click the link to view,there only have 5 issues.

As this is counting based on history data, it's not possible to create a filter that matches the exact conditions. The linked filter is an approximation for issues created in those date ranges. Note that the "resolved" number is not linked, as we don't have a searchable resolution date.
And, as the definition of this count, the number are the resolution events, so a single issue that has been reopened and resolved several times, will be counted as >1 in this summary.

bigjason

bigjason

2019-05-08 20:50

reporter   ~0062042

Sorry to miss this message in version 2.20, now I understand this.

bigjason

bigjason

2019-05-12 23:57

reporter   ~0062057

Last edited: 2019-05-12 23:58

the Opened number at days 180 & 365 is more than the actual issues number.

In "By Date (days)", it use "har_bug_history_table.date_modified" to filter the range of days;
but the same range in View Issues section is used in the "Filter by Date Submitted" filters and filtered by "har_bug_table.date_submitted".
Can synchronize the filtering conditions on both sides?

Related Changesets

MantisBT: master-2.21 c0d84a84

2019-05-08 05:55

cproensa

Committer: dregad


Details Diff
Fix summary by date added count

In summary page, count by date ranges, the ranges with 0 events did not
have the correct accumulated count.

Fixes 0025742
Affected Issues
0025742
mod - core/summary_api.php Diff File