View command works even after another view has been issued

[woojiahao]

1. view 2
2. view 1 repeatedly and it says that "Viewed Person Successfully" but the view does not change to the first person

Can be misleading for end user

[soc-se-bot]

Team's Response

This is essentially the same problem as #5848, as after view 2, the current list will only contain the person viewed. So view 1 will only show the first person on the list.

The 'Original' Bug

[The team marked this bug as a duplicate of the following bug]

Message from the app is not showing correctly.

Here is the the list.

I view the person with index 7. After I view the person, I got this.

After that I try to view person 1, the app says that I am able to view it successfully but I am still viewing person 7 according to the list in the first screenshot.

---

_{[original: nus-cs2103-AY2324S1/pe-interim#5744] [original labels: type.FeatureFlaw severity.Medium]}

Their Response to the 'Original' Bug

[This is the team's response to the above 'original' bug]

Thanks for pointing this out. While we do agree that this is an issue for the user, we disagree with the severity being "Medium". However, we feel that the severity is "Low" instead based on the following points: 1) Firstly, the user may not know what previous list that the user was viewing might be, thus not being able to even view the person based on the index of the previously viewed list 2) This happens very rarely as most users will go back to the list first before viewing the specific person. 3) It causes a very minor inconvenience to the user as no data is manipulated and the user can clearly tell that he/she is viewing the same user as before.

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 type Team chose [`type.FeatureFlaw`] Originally [`type.FunctionalityBug`] - [x] I disagree **Reason for disagreement:** This is a **FunctionalityBug** because the view command's intended usage is as such:  In the UG, it specifies that the index should be from `[1, last index on filtered address book list]`. However, they do not specify nor clarify that after applying `view` the list will be filtered and as such, only have 1 remaining entry.  It is this ambiguity that makes it NOT work as specified (by definition of a **FunctionalityBug**) since without clarification, users will be under the impression that the previous address book list is still available, hence why they would try `view n` where `n != previously searched index` and the outcome (i.e. viewing the same entry rather than changing entries) goes against the expected output given the expectation set in the UG.

---

## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** > Firstly, the user may not know what previous list that the user was viewing might be, thus not being able to even view the person based on the index of the previously viewed list I fail to see how this is an issue on the user side. The user knows what the previous list was since they would have been the one issuing commands. > This happens very rarely as most users will go back to the list first before viewing the specific person. The user might also have a list of indices that they want to check such as wanting to view 10 indices that they had collated from viewing the original address book list. This bug could hinder the user from quickly viewing these 10 users. > It causes a very minor inconvenience to the user as no data is manipulated and the user can clearly tell that he/she is viewing the same user as before. While this may be true, it does not stop it from behaving out of the realm of expectation. As I have laid out in my reasons for why this is a **FunctionalityBug**, the user's expectation with the `view` command is to be able to view the details of the persons given the "last index of the filtered address book list". Given that there is no clarification that a filter is applied after `view`, the users would be under the impression that the underlying address book list would contain more than just one entry and as such, continue to apply the `view` command and fail at changing the user.

---