Location field: Does not trim in between spaces

[GlendaChong]

Input Deck and D eck are considered non duplicates, even though they of the same location.

This should not have been allowed, given that stalls with same locations are considered duplicates too. It is common that users may add spaces between locations, like for two words locations, as shown in the images below.

[nus-se-script]

Team's Response

We will reject this as it is simply a typo on the user's part that causes the location of the stall to become different than any that exists in the stall already, even if that difference is just 1 character.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

• [x] I disagree

Reason for disagreement: I believe that this feature flaw should be accepted, rather than rejected or NotInScope, as fixing this feature flaw is essential for the app to be reasonably useful.

This feature flaw suggestion ensures that the duplicate detection of the app is truly accurate. While the team now deems "techno edge" (with one space) and "techno edge" (with 2 spaces) as non-duplicates, these 2 locations are unlikely to mean 2 different locations, and hence potentially an input of a duplicate item, especially with the same stall name. While the team argues that this is a typo on the user's end, which is true, the app could have given a warning in such near match cases so that the user can make the final decision. I agree that input with one spaces like Deck and D eck might be a possible non-duplicate, but inputs with multiple spaces in between the exact same words are most likely duplicates.

Furthermore, according to the website:

If you app has a duplicate detection feature, make sure its limitations are made clear to the user so that users are not led to believe that duplicates are being detected while many potential duplicate cases go undetected. Otherwise, it can be considered a type.FeatureFlaw.

Such limitations of the app for the duplicate detection feature is not made known to users, as shown in the UG screenshot below (only case-insensitive feature is made known), which is why this issue is a valid FeatureFlaw, which will make the duplicate detection feature more complete than in v1.4.

Also, to classify a feature flaw as NotInScope, the team has to satisfy these conditions according to the website:

In addition, the following (at least one) need to be satisfied:

• The UG specifies it as not supported or coming in a future version.
• The user cannot attempt to use the missing feature or when the user does so, the software fails gracefully, possibly with a suitable error message i.e., the software should not crash.

In this case, the UG did not specify anything about this feature flaw, as stated earlier. Also, the user can attempt to use the add-stall feature and there's no suitable error message, but simply go past the duplicate detection. Hence, none of the 2 conditions are satisfied. Therefore, this valid feature flaw is not considered NotInScope, but a bug that has to be accepted and fixed.

Such a fix will also not require much effort, as it can be done by simply replacing the multiple spaces in between the words to just a single space (i.e. multiple spaces between words techno and edge can be replaced into a single space, single space between words will remain as single space), before performing the equality check of the location_names.

---

## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]

---