search

leeyiheng12 / pe

0 stars 0 forks source link

Unable to edit application when there is a slash in the company name #3

Open leeyiheng12 opened 2 years ago

leeyiheng12 commented 2 years ago

Steps to reproduce:

1) Enter: edit 1 n/Microsoft/Google

Expected behaviour:

Application edited, with name of the company as "Microsoft/Google"

Actual behaviour:

Unable to add application, with error message "Names should only contain alphanumeric characters and spaces, and it should not be blank", even though UG did not specify this constraint

Screenshot:

image.png

soc-pe-bot commented 2 years ago

Team's Response

Same reasoning as in #675

The 'Original' Bug

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

Unable to add application when there is a slash in the company name

Steps to reproduce:

1) Enter: add n/TestCompany/TestCompany j/TestJob p/1234 e/testemail@test.sg a/TestAddress t/SoftwareEngineering pt/HIGH ast/ACCEPTED t/BasedInSingapore

Expected behaviour:

Application added, with name of the company as "TestCompany/TestCompany"

Actual behaviour:

Unable to add application, with error message "Names should only contain alphanumeric characters and spaces, and it should not be blank", even though UG did not specify this constraint

Screenshot:

image.png

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

Their Response to the 'Original' Bug

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

Reject this Bug. As it is documented in the application the error message specifically, hence the user is provided the correct information and does not affect the functionality of the application Alternatively, this would be a VeryLow Severity Documentation Bug since the error message is accurate but the constraint is missing from the UG.

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: Just because the team can fix both bugs the same way (editing the regex constraint of the name field), from the user's point of view, there are two different functionalities in question here (add and edit). Even in practice, for publicly available apps, just because a team can fix multiple different bugs by editing the same piece of code associated with it, does not mean that those bugs are different. In this case, two different commands are in play, and will be experienced by the user at two different stages of usage of the app.

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: The fact remains that the app's behaviour differs from the UG. One would expect the UG to provide correct instructions on how to use the app. If the UG was intended to be unclear and/or provide different instructions from what the app promises, then it would go against the purpose of having the UG. In this case, by following the UG, the user would be unable to perform a task that he/she expected to be able to perform, thus it is still a bug.

:question: Issue type

Team chose [type.DocumentationBug] Originally [type.FunctionalityBug]

Reason for disagreement: [replace this with your explanation]

:question: Issue severity

Team chose [severity.VeryLow] Originally [severity.Medium]

Reason for disagreement: According to the CS2103 website, bugs of severity "VeryLow" are flaws that do not affect usage, and only cosmetic problems should have this label. The differing instructions between the UG and the app affects usage directly (the app cannot deliver what the UG promised, and stopped the user), and is more than a cosmetic problem.