search

qianz-z / pe

0 stars 0 forks source link

Add Command incorrect parsing of address (with unit number) #8

Open qianz-z opened 2 years ago

qianz-z commented 2 years ago

As shown in the image, the first 2 inputs do have unit level and number, however the program throws an error saying that the address provided is invalid. It is only with trial and error that I manage to understand that the unit level and number do not accept 1 digit. However, the error message does not reflect what was wrong (as it was a generic error message and the format was correct) and the UG did not specify that 1 digit unit level and number is not allowed.

To replicate: add -property n/Ash Ketchun a/1 Lower Changi #1-1, S121111 p/16002 t/Condo add -property n/Ash Ketchun a/1 Lower Changi #01-1, S121111 p/16002 t/Condo image.png

soc-se-bot commented 2 years ago

Team's Response

According to Inland Revenue Authority of Singapore (IRAS) , the normal address unit level and number compliance requires them to have at least two digits starting from 01 onwards as shown below.

image.png

image.png

Furthermore, it is actually close to common to know that in Singapore when writing "single digit" unit level/number, they should have a 0 as the first digit as stated in the compliance by IRAS, which is extremely applicable with regards to the target users, Singapore property agents, who are dealing with addresses on a daily basis. Hence, it is assumed that there is no need for explicit "redundant" explanation for unit level/number.

Since the product is designed with the compliance in mind and is working as intended, it should not be flagged as a Functionality bug.

However, this brings in the possibility of feature optimization which allows unit level/number like #1-1 or #01-1 to be accepted but stored as #01-01 (proper format according to compliance). As feature can be further optimized, bug type should become FeatureFlaw instead. This is also one of the reasons for not explicitly saying that unit level/number like #1-1 or #01-1 are not allowed in UG since they can be allowed after such optimization in the future!

But since such feature optimization was not planned for v2.1 where for add -property feature, the main focus lies on the validation between mismatched address format and unit type of property which took a lot of time to research (15 unit types) and implement, along with current feature working correctly as intended, this valid bug shall be categorized as NotInScope.

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

Reason for disagreement: [replace this with your explanation]

:question: Issue type

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

Reason for disagreement: [replace this with your explanation]