IronBiscuit / pe

0 stars 0 forks source link

Delete doesn't work immediately after a filter function #5

Open IronBiscuit opened 3 years ago

IronBiscuit commented 3 years ago

image.png

The above image shows the expenses that is stored within the application. Below what the application shows after i enter filter-t 3650

image.png

Everything is working so far, however when I entered delete 1 immediately after that, below is what I got even though I expected the command to work as the expense at index 1 does exist.

image.png

nus-se-bot commented 3 years ago

Team's Response

The issue reported does not make sense. If users want to delete a certain expense, they should be only be deleting the expense that is currently shown on the displayed list. <- This is what our delete feature works. So if the display list is empty, "delete 1" will give you error because of invalid index

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: Thank you for responding to the issue.

After reading the response, I have a clearer understanding of not only the delete function, but also the functions of the other commands that require an index as an input.

Unfortunately, I believe it is not good enough to learn the functionalities of an application through an issue response. The documentation of an application (the UG / DG) should be clear as to what the pre-requisites of using a command are. In this case, having the list displayed before using commands that involve an index seems to be such a pre-requisite for commands that require an index input.

image.png

The above is a small excerpt obtained from the application's User Guide, under section 3.6. Similar excerpts can be obtained from other commands but this is a good enough example. In this excerpt, it is made clear that the index taken in refers to the index number shown in the expense list. However, no evidence of the necessity of having the list displayed before using the command can be found. A typical user would thus likely infer that as long as the index is valid, all he/she needs to do is to enter the command to execute it. Having the list displayed before the command can be executed is not intuitive, and thus should have been made clear in the UG

image.png This problem is exacerbated by the above image, which is an excerpt obtained from the application's Developer Guide, under section 6.8. Similar excerpts can be obtained from other commands but this is a good enough example. In this case, it is made clear that the only pre-requisite is for the expense book to not be empty, which has been fulfilled in my testing. Once again, no evidence of having the list displayed before usage has been made clear.

With all that said, I believe that there is a clear issue here. Therefore, I do think the rejection of the issue is unjustified and should be reconsidered.