soc-se-bot
commented
3 months ago Team's Response
Please refer: https://nus-cs2103-ay2324s2.github.io/website/admin/tp-pe.html#pe-phase-2-developer-response
As per ITU-T recommendation E.164 for the international telephone network, the specification of an entire phone number (including country code) should be at most 15 characters. [1] [2]. Hence, there is ground to believe such an input can only happen in case of deliberate sabotage, in which case it should not be considered a bug. Additionally, the input provided by the tester shows a phone number with more than 100+ digits, which goes above and beyond the example given in the CS2103/T example of deliberate sabotage.
Hence, in accordance to CS2103/T policy, it should not be considered a bug.
1: https://www.itu.int/ITU-T/recommendations/rec.aspx?rec=E.164 2: https://stackoverflow.com/questions/723587/whats-the-longest-possible-worldwide-phone-number-i-should-consider-in-sql-varc
The 'Original' Bug
[The team marked this bug as a duplicate of the following bug]
Unable to see the full phone number
Unable to see the full phone number
[original: nus-cs2103-AY2324S2/pe-interim#3868] [original labels: type.FunctionalityBug severity.Low]
Their Response to the 'Original' Bug
[This is the team's response to the above 'original' bug]
Please refer: https://nus-cs2103-ay2324s2.github.io/website/admin/tp-pe.html#pe-phase-2-developer-response
As per ITU-T recommendation E.164 for the international telephone network, the specification of an entire phone number (including country code) should be at most 15 characters. [1] [2]. Hence, there is ground to believe such an input can only happen in case of deliberate sabotage, in which case it should not be considered a bug. Additionally, the input provided by the tester shows a phone number with more than 40+ digits, which goes above and beyond the example given in the CS2103/T example of deliberate sabotage.
Hence, in accordance to CS2103/T policy, it should not be considered a bug.
1: https://www.itu.int/ITU-T/recommendations/rec.aspx?rec=E.164 2: https://stackoverflow.com/questions/723587/whats-the-longest-possible-worldwide-phone-number-i-should-consider-in-sql-varc
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:** My original intent was not to test the system's capacity to handle an excessively long single phone number but to demonstrate a realistic and practical limitation in managing multiple phone numbers per contact. The application currently allows the input of more than 15 characters in the phone number field. According to ITU-T recommendation E.164, the standard for the international telephone network, a single phone number, including country code, should not exceed 15 digits. This design choice in our application could lead users to mistakenly believe that they are permitted to enter multiple phone numbers within a single input field, especially since more than 15 characters can be entered without restrictions. In practical scenarios, it is common for individuals to have multiple contact numbers (such as work, home, and mobile). The current system design only allows numeric inputs without any separators like spaces or commas. This restriction significantly limits the functionality's usefulness, as it does not align with how users typically manage multiple phone numbers in contact databases. Users may attempt to input several numbers concatenated together, resulting in confusion and potential misuse of the data.
## :question: Issue type Team chose [`type.FunctionalityBug`] Originally [`type.FeatureFlaw`] - [x] I disagree **Reason for disagreement:** This issue should not be classified as a functionality bug, as the application behaves as currently specified when inputting a long number. This issue should be classified as a feature flaw because it directly impacts the completeness and usability of the phone number management feature. The feature as implemented does not fully serve the needs of users who require management of multiple contact numbers, a standard expectation in today’s communication environment. The lack of functionality to input and distinguish between multiple phone numbers compromises the integrity of the contact management feature, making it incomplete for normal usage expected by the target users.
Description: The application does not restrict the length of phone numbers entered by users, leading to display problems in the user interface where long phone numbers are not fully visible. This can hinder user interaction and affect the usability of the application, particularly for cases where users have very long phone numbers or multiple phone numbers.
Steps to reproduce: When adding a new person, enter a long phone number.
Expected Behavior: The application should handle phone numbers in a way that ensures they fit within the UI constraints or provide an effective method to manage phone numbers that exceed these lengths.
Actual Behavior: Phone numbers that are too long for the display area are cut off.
When the phone number gets too long, it shows this:
Suggested Improvement: Introduce a validation rule to limit the maximum length of phone numbers based on the UI's display capabilities. Alternatively, implement a UI design that accommodates longer phone numbers, such as truncation with a tooltip that shows the full phone number on hover or a click-to-expand functionality.