Open JonathanHoshi opened 2 years ago
The example provided in the add command section was solely used for an example of what a valid add command would look like and what would be the expected result. The system behaviour works correctly by verifying that the candidate already exists. In the event the user is adding an actual candidate, the candidate would be uniquely identified by his/her student id/nus email/phone, which eliminates the issue of the tester not being able to figure out the duplicate. A simple find would also enable the tester to easily figure out which field is duplicated in the system. Hence we believe that this report should be rejected.
With reference to the first provided screenshot (#1), under the PE guidelines, the prof has also mentioned that it is important to verify copied text from PDF. The invalid input is a result of the tester copying from the pdf directly without checks on the spacing that might be affected by copying which is hence not considered a bug and is thus rejected.
Team chose [response.Rejected
]
Reason for disagreement: ## Reason I agree with the team that the examples are just a guide to show users on how to use the command. However, my main reason as mentioned in my previous quote is also that the feedback message is not friendly for users to know whether which fields are duplicated.
Since the candidate in the list does not show their email or phone number, it is hard for me to know what kind of phone numbers or email already exists. This makes it hard to know whether what fields have already been use for testing. It is also extremely tedious to use the 'focus' command to note what kind of information is already inside without deleting all the information that is present.
This makes it hard for users to not know whether which part of their input is a duplicated entry as the application only shows that The candidate already exist in the system.
Details
Screenshot
1
2