Questions on bug fixes vs feature freeze

[HmuuMyatMoe]

For our application, we have an "Add supplier" feature where the user is able to add a supplier's email.

When checking for validity of the email, we only checked for the email to have a local part @ domain name (so abc@abc and abc@abc.com were both considered valid). We did not state that ".com" was compulsory in both our error message and our user guide. However, we received feedback from our PE Dry run tester that this was a functionality bug.

While it is common for emails to have a ".com" behind, in this case, would it be more of a feature flaw instead of a bug?

Or would it fall under the following category as a type of bug that we can fix? Thank you!

[HmuuMyatMoe]

We also had a similar issue with the checking of a supplier's phone number where we only checked and made sure that the phone number was at least 3 digits. Our error message for phone number validity check did state that the phone number should have "at least 3 digits" but it is not specified in the UG. We received 2 functionality bug reports that

1. Allowing for 3 digits phone numbers was a functionality bug
2. Allowing for phone numbers more than 8 digits was a functionality bug

It is indeed common for phone numbers to be 8 digits so would it also be considered a bug under the following category which we be allowed to fix (make it so that only phone numbers that are exactly 8 digits are accepted)? Thank you!

[damithc]

@HmuuMyatMoe In general, stricter validation of inputs are nice-to-have enhancements that can be postponed to a future version. They are not a bugs that need to be fixed in v1.4,

[HmuuMyatMoe]

Thank you, prof! In this case, would it suffice to specify the validity requirements of the inputs in our UG?

[damithc]

Thank you, prof! In this case, would it suffice to specify the validity requirements of the inputs in our UG?

@HmuuMyatMoe You can update the UG to clarify the current behavior.

[HmuuMyatMoe]

Thank you!