search

waihongteh / pe

0 stars 0 forks source link

Incorrect handling of addresses #8

Open waihongteh opened 1 week ago

waihongteh commented 1 week ago

add n/Apple Corp p/4089961010 e/contact@apple.com a/t/FAANG t/tech Here's the input i provided. It leads to a severe error where the tag is misunderstood as the address. Perhaps you should find a way to disallow or check for / character in address? image.png

Also, when I input the following: add n/Appl p/4089961010 e/contact@apple.com a/1 Apple Park Way, Cupertino, CA app/2 image.png The system does not alert me that there is an additional parameter. Instead, it treats the additional parameter as part of the address.

soc-se-bot commented 4 days ago

Team's Response

Response

We have confirmed that there are many addresses that contain the '/' character, so we cannot restrict users from including strings like "t/FAANG" or "app/2" in their addresses. Address parsing falls outside the intended scope of our project, as we operate under the assumption that users are not attempting to deliberately sabotage the program. Therefore, we think that this should be clssified as NotInScope.

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

Reason for disagreement: First, thank you for the response. I understand that you try to argue that this is not in scope, since Address parsing falls outside the intended scope of our project, as we operate under the assumption that users are not attempting to deliberately sabotage the program. However, according to CS2103T website,

image.png

Nevertheless, your application does not seem to fulfil any of the 2.

  1. The User Guide Does Not Specify the Behavior

    • One criterion for something to be considered response.NotInScope is that the User Guide (UG) specifies the feature as unsupported or planned for future implementation. In this case, there is no mention in the UG about how addresses containing special characters like / should be handled.
    • Furthermore, the UG does not provide any constraints or formatting requirements for addresses, which leads to unexpected and incorrect behavior. The lack of such documentation means this is not a deliberate omission but a flaw in the implementation.

  2. The Software Fails to Handle the Input Gracefully

    • For an issue to be response.NotInScope, the software must either prevent the user from using the unsupported feature or fail gracefully when it happens (e.g., by providing a suitable error message).
    • However, in this scenario: The system does not alert the user that additional parameters are being misinterpreted as part of the address field. The system silently accepts the erroneous input and generates an incorrect record, leading to confusion and inconsistency in the data. This is neither a graceful failure nor proper validation of user input.

  3. This Is a Valid Bug, Not a Feature Request

    • The issue is not about implementing a new feature or improving a suboptimal design but fixing a bug where input parsing fails to behave as expected. Users providing a valid command with plausible inputs like t/FAANG or app/2 are experiencing unintended consequences due to poor input validation, which is a clear flaw in the system.

  4. Addressing This Bug Is Less Effort Than Its Consequences

    • According to the definition, an issue can be considered response.NotInScope if the “better” implementation would take significantly more effort than the current one.
    • However, implementing stricter input validation (e.g., ensuring proper parsing of fields or disallowing ambiguous inputs) or adding documentation is not an overly complicated fix. Leaving this issue unaddressed, on the other hand, increases user confusion and potential data errors, which have a higher long-term cost.

I hope that this clarify why it does not fall within NotInScope. Thank you!