Inaccurate Phone Number Sorting

Overview

Sorting by phone numbers does not sort as expected. According to the User Guide:

sort d/phone sorts the applicant list by phone numbers in ascending order.

The natural expectation here is that phone numbers will be sorted in ascending order of value. For example, a phone number 500 should come after 100 because it is larger in value (500 > 100).

This is not the case for certain combinations of data in Staff-Snap. I've provided an example below.

Reproduction Steps

Clear the home directory and run Staff-Snap
Run the command clear to start with a fresh state

Run these three commands to populate the data

add n/A hp/100 e/clarence@gmail.com p/AA
add n/B hp/1000 e/clarenc1@gmail.com p/BB
add n/C hp/102 e/clarenc2@gmail.com p/CC

Run sort d/phone and observe the ordering of the interviewee. Below I've attached a screenshot:

Notice that the B candidate is not sorted to the bottom of the list. Given that 1000 is larger than all the other phone numbers, it's expected that it B should be sorted to the bottom of the list.

Impact

The flaw could cause much confusion for users, especially those with many candidates (as we'd expect from the number of applicants companies are getting these days). As such, it's important that the sort functionality works properly as when looking through the many candidates, we rely on features like sorting to comb through the many candidates.

Team's Response

Hi, thanks for catching the bug, definitely something we did not expect!

We accept that this could be an issue, however we believe that it should be considered as low severity, as this issue would only appear in cases where a phone number is a different length from other phone numbers. In most countries around the world, their phone numbers have the same length, and thus such an issue would not appear. We do accept that it could occur if a foreign applicant were to apply to the company, however even in this case the minor inconvenience of calling the applicant with phone number 100 and 1000 before 102 does not affect any usage of the app, as the only thing it way it would affect the user is who they called first.

As a user would expect to have applicants go through at least a few rounds of interviews and then give them a corresponding score in our app, then sorting by score to decide who to move on to the next round or offer a job, we thus believe that this bug is largely inconsequential and only causes a minor inconvenience to the user.

Hence as this is a largely inconsequential bug, we have decided to lower its severity from medium to low, hope you can understand where we are coming from!

lordidiot / pe