search

dedsecrattle / pe

0 stars 0 forks source link

Invalid Email Allowed within the Application #4

Open dedsecrattle opened 2 months ago

dedsecrattle commented 2 months ago

image.png

Command executed - edit 1 /e test@example

Since, test@example is not really a valid email as it doesn't contains a top level domain e.g .com , .in ,etc

Such invalid Entries can cause data inconsistency , if user accidentally forgets to type in the domain

nus-pe-script commented 2 months ago

Team's Response

No details provided by team.

The 'Original' Bug

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

Wrong email format is supported

image.png It should not support this type of email. like 123@123

[original: nus-cs2103-AY2324S2/pe-interim#5539] [original labels: severity.Low type.FeatureFlaw]

Their Response to the 'Original' Bug

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

Under QnA for what can be fixed for PED bugs: [Q5] Can we tweak validity checks for a user input, or error/exception handling? A: • Can be allowed only if the current behavior causes the software to misbehave (i.e., crash, give incorrect results, store inconsistent data, or make it unusable for typical users). • Accepting seemingly 'unsuitable' values for an input (e.g., accepting numbers for a person name, empty value as a parameter): This is not considered 'incorrect' (giving more freedom to the user is not necessarily incorrect) unless those unsuitable values causes the application to misbehave. • Accepting supposedly invalid values (e.g., end date is earlier than start date; February 30th) is, while not ideal, not necessarily incorrect either (i.e., adopting a garbage-in garbage-out approach to input validation). However, if such data can make other things go haywire (e.g., crash the app, corrupt the data file), accepting them can be considered a bug, and fixed.

Although the suggestion is valid, the specified invalid input does not cause the product to misbehave, and should not be considered a bug.

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 severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** I would still consider this as a Medium Severity reasons - let's say the user wants to record person `John` with the email `john@example.com` Users quite often make mistakes while recording the data let's say a user forgets to type the top-level domain i.e. user records john@example, since there is no checking done for such invalid emails, in the current application this will be executed successfully and doesn't throw an error to the user but such an entry can cause data inconsistency as later on if user want to retrieve the email for `john` he won't be able to get the correct email which entirely questions the data integrity within the application. Checking for invalid email will report the error to the user at the time of entry and user will rectify his mistake to maintain the data integrity and consistency. and Since such cases can happen quite often we can't classify this as `low` and given the outcome of such a mistake can affect the usability of the Application , I would consider this as a `medium` severity bug