nus-se-bot
commented
1 year ago Team's Response
Hi this is an intended behavior of our product. Adding an income and expense shares the same category list, which users can choose whichever fits their situation. We are not limiting which category tags that choose. Furthermore, the users can choose the edit the tag if they deem not suitable. This does not affect the normal operation of the product, which we will be rejecting.
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:** By the very fact that you propose working on this in your next iteration, you agree it is an issue that should be remedied. Thus it should be response.notInScope
As a user, I would not classify my salary as an expense, even if I am an employer that is paying salaries, it would probably be something like a work expense instead since salary implies a gain in income. I suggest removing SALARY from the available types in addExpense