Team's Response

The purpose of optional prefixes under statsbasic is to increase the convenience for the user as they do not need to manually calculate all the bounds of their intended interval.

The “weird value” for the end date is an intended result of using the configuration that uses only a start date as shown in the tips, whose value is correctly calculated by adding the period(100 years) to the start date and -1 day, on the day of testing. From the looks of the period, it is likely that the command is done on the Default Budget. It is also stated in the User Guide that the Default Budget “holds all expenses from deleted budgets” as shown here and the large period is designed for this purpose. More reasons why statistics should not be done in the Default Budget can be found in point 4 , which is also quoted below:

Even though the Default Budget can contain expenses and has a valid budget period, it is not recommended to type this command when in that budget. It is after all a placeholder budget that is meant to hold expenses not associated to any budgets when starting out, which also implies it doesn’t support editing any of its attributes, especially period. Also, the budget period is set to a large interval by design, so the output might not make sense.

Extra information regarding the interval value-adds to the user especially since users can verify that the app calculates statistics with the intended interval on the new Statistics Panel itself, which contains little information about the included expenses. As such, I will be rejecting this bug report under type.FeatureFlaw

type.FeatureFlaw: Some functionality missing from a feature delivered in v1.4 in a way that the feature becomes less useful to the intended target user for normal usage. i.e., the feature is not 'complete'. In other words, an acceptance testing bug that falls within the scope of v1.4 features. These issues are counted against the 'depth and completeness' of the feature.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

[x] I disagree

Reason for disagreement: Thank you for the response.

Although it does value-add the user in showing more information, displaying the end date in that manner shows lack of completeness/polish in the function by confusing the user. As my role of Acceptance Tester, I believe that system output should not confuse the user.

Thus, I feel that it is still a feature flaw in terms of completeness and the issue should not be rejected.

Nanosync / pe

Stats bug: unknown end value for end date #8

Team's Response

Items for the Tester to Verify

:question: Issue response