search

heeeyi / pe

0 stars 0 forks source link

Multiple same titles allowed, but only the last one taken #3

Open heeeyi opened 1 year ago

heeeyi commented 1 year ago

image.png

This app currently allows multiple "titles" to be specified, and the system take the last one. However, it is not specified in DG or UG that the system will have such behaviour. If I was the user, I may expect the first one to be the real title, while the next one is a mistyped prefix for d/ or i/

soc-pe-bot commented 1 year ago

Team's Response

No details provided by team.

The 'Original' Bug

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

Unclear over what is "one command flag" for find command

find r/aaa r/aaa This would work, but some users may think that 2 command flags are present and hence are expecting an error

I rate this a documentation bug as it should be changed to "one type of command flag". I rate it severity.low as it only affects users in rare cases. It is not severity.verylow as it is more than cosmetic error

[original: nus-cs2103-AY2223S2/pe-interim#3908] [original labels: severity.Low type.DocumentationBug]

Their Response to the 'Original' Bug

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

Yes, we forgot to mention in the UG that we will take the last entry if there are many entries of the same command flag.

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)

Reason for disagreement: This is not the same as the other bug. The other is only referring to the "one command flag" issue regarding "find" command, which is recorded in UG. However, my issue is referring to the special behaviour of t/, that is implemented but not recorded in UG and DG. Under this behaviour, if the command itself does not accept multiple value of the field following t/, then when you specify multiple copies of t/, only the value following the last one will be taken. I feel this very important to be documented.

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