waihongteh / pe

0 stars 0 forks source link

Multiple parameters allowed in commands. #14

Open waihongteh opened 1 week ago

waihongteh commented 1 week ago

For apply command, apply 1 n/SWE Intern d/Requires Java as/APPLIED as/OA, ignores the first as parameter, which is not a correct behaviour. Similar goes for update c/1 app/2 as/OA c/2 app/3 app/4 as/REJECTED. Both duplicated tags are not detected by the system, which is not supposed to be the case. A correct system should be able to detect it and alert the user.

nus-pe-bot commented 1 week ago

Team's Response

Response

Duplicate of #3051

We are marking this issue as NotInScope as it is already documented as a known limitation in our User Guide under sections #4 and #5. Additionally, after consulting with Prof. Damith, we have confirmed that this does not qualify as a bug. For further context, please refer to the discussion in this forum thread.

We agree with Prof that allowing multiple as/ fields for updating applications could be beneficial, especially for users prone to making typos. Instead of backspacing to correct errors, they can conveniently add a new field. As such, we have classified this issue as Low severity.

The 'Original' Bug

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

Able to enter multiple fields for some commands

The following command: apply 2 n/Product Management Intern d/Requires Figma as/OA as/REJECTED

does not raise an error or warning to the user, and only the last as/ field is used as the application status.

Similarly for the update command, users can add multiple c/, app/ and as/ fields, with only the last instance of each being used.

For c/ as/, this does not make sense. However, for app/, one can argue that changing the status of multiple applications at once is useful to the user and hence can be kept. However, in any case, it should update all the app/ fields that are given, instead of only the final one.


[original: nus-cs2103-AY2425S1/pe-interim#1566] [original labels: severity.Medium type.FunctionalityBug]

Their Response to the 'Original' Bug

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

Response

We are marking this issue as NotInScope as it is already documented as a known limitation in our User Guide under sections #4 and #5. Additionally, after consulting with Prof. Damith, we have confirmed that this does not qualify as a bug. For further context, please refer to the discussion in this forum thread.

We agree with Prof that allowing multiple as/ fields for updating applications could be beneficial, especially for users prone to making typos. Instead of backspacing to correct errors, they can conveniently add a new field. As such, we have classified this issue as Low severity.

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: [replace this with your explanation]


## :question: Issue response Team chose [`response.NotInScope`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]
## :question: Issue type Team chose [`type.FunctionalityBug`] Originally [`type.FeatureFlaw`] - [x] I disagree **Reason for disagreement:** Thank you for the response. While I agree that this could be NotInScope, I do not agree that it is a functionality bug. Here's why: ![image.png](https://raw.githubusercontent.com/waihongteh/pe/main/files/285f1914-a87a-42a0-81c6-693b34226f72.png) 1. Only feature flaw can be classified as **NotInScope**, this is a clear stance that justifies that it should be a **FeatureFlaw** instead of **FunctionalityBug**. If you insist that it is a **Functionality Bug**, then the classification for **NotInScope** is by definition incorrect. 2. The behaviour is clearly documented in the **Known Issues** section. Hence, it is the intended behaviour of the system, which falls under FeatureFlaw. 3. According to your response, `We agree with Prof that allowing multiple as/ fields for updating applications could be beneficial, especially for users prone to making typos. Instead of backspacing to correct errors, they can conveniently add a new field. As such, we have classified this issue as Low severity.` It is a subjective design decision that does not fall under **FunctionalityBug**, but under **FeatureFlaw**.