History feature prints backend of the application

[sdevih]

Description

Command history gives an example usage for the history command, but when the command history is listed, the backend of the message is printed, and this behaviour differs from normal expectations as the target audience of tutors will not understand the backend workings of the application and may be quite inconvenient to users to utilise the feature.

Steps to reproduce

1. history

Expected

• User-friendly interface which shows the actual input written on CLI. For example, "FindCommand{find crown}

Actual

• command showcases backend workings such as FindCommand{predicate={seedu....}

Screenshot

[nus-pe-script]

Team's Response

No details provided by team.

The 'Original' Bug

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

History is not in a human readable format

To replicate this bug, type the history command:

history

This view is not human readable.

---

_{[original: nus-cs2103-AY2324S2/pe-interim#1081] [original labels: severity.Low type.FeatureFlaw]}

Their Response to the 'Original' Bug

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

Thanks for raising this. This has been addressed in our "Planned Enhancement" as the history stored is not very user-friendly as of this iteration. This will be improved in the future.

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:** Thank you for your response! While I recognise that this was addressed in the planned enhancements and the flaws addressed in the planned enhancements are 'known', the bugs can still be reported if the enhancements themselves are flawed/inadequate.  Currently, the application prints out the backend of what the command does which the user will not understand as it is not user-friendly. Yet, the future plan to show the command output (as seen below) will not fix the issue at hand as it will still showcase verbose code that is not user-friendly. Perhaps the team meant to say command input, which is a typo. In this case, the planned enhancements themselves are flawed, it would be more accurate to classify this bug as not in scope.  However, since the definition of a bug of severity.veryLow (which includes typo) mentions that it is a flaw that is purely cosmetic and does not affect usage. I believe that the current issue severity chosen by the team (Low) applied since this typo

---

## :question: Issue type Team chose [`type.FeatureFlaw`] Originally [`type.FunctionalityBug`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]

---

## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** I believe that the bug is of severity veryLow, since in the planned enhancement for it, command input should be actually be command output which is a typo and can be classified as cosmetic. Yet this does cause the planned enhancement to be flawed/inadequate.

---