nus-pe-script
commented
1 year ago Team's Response
This is an intended behavior of our program as both our income and expense share the same category tags, and we don't think this is a bug. We have a list of category tags for users to enter. And they can choose whichever tag that they want. We do not restrict what tag that want to enter (ie, entering SALARY tag when adding Expense). This is because the user can always edit the tag that when necessary. In our help messages and UG, we did mentioned the category tags that can be entered by users, which shows the same category list for both income and expense.
In our future iteration, we can perhaps split the category tags into two, one for income, and one for expense. But this version, we choose not to, as we didn't find a need for it, as the users can just edit it themselves.
The 'Original' Bug
[The team marked this bug as a duplicate of the following bug]
'SALARY' should not be expense
- I think that Salary category should only be available for addIncome, it shouldn't be an expense.
- I believe think that FOOD, SHOPPING, GROCERIES, TRANSPORTATION, TRAVEL are not income.
[original: nus-cs2113-AY2223S2/pe-interim#2344] [original labels: severity.Medium type.FeatureFlaw]
Their Response to the 'Original' Bug
[This is the team's response to the above 'original' bug]
This is an intended behavior of our program as both our income and expense share the same category tags, and we don't think this is a bug. We have a list of category tags for users to enter. And they can choose whichever tag that they want. We do not restrict what tag that want to enter (ie, entering SALARY tag when adding Expense). This is because the user can always edit the tag that when necessary. In our help messages and UG, we did mentioned the category tags that can be entered by users, which shows the same category list for both income and expense.
In our future iteration, we can perhaps split the category tags into two, one for income, and one for expense. But this version, we choose not to, as we didn't find a need for it.
Items for the Tester to Verify
:question: Issue duplicate status
Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)
- [ ] I disagree
Reason for disagreement: [replace this with your explanation]
## :question: Issue response Team chose [`response.Rejected`] - [x] I disagree **Reason for disagreement:** The very fact that you propose a change in the next iteration to remedy this issue implies your agreement that it is an issue. Thus it should be response.notInScope over rejected.
Currently I can put the type of income added to be categories I would spend on such as GROCERIES, while I as a user would not be gaining income from groceries. If I worked at a supermarket it would be of type income. It is unnatural for income to have these available types. I suggest limiting the types of income to a more select few