nus-pe-bot
commented
3 years ago Team's Response
As mentioned in the first sentence of the enrol command, dogs cannot be enrolled in the same program. Hence, the command enrol d/12 p/6 p/10 throws the error stating that dog has already been enrolled in one or more programs.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: I disagree with the Dev Teams response to my original bug report.
With this, I think the Bug Type label of my original bug report should have been FeatureFlaw rather than a FunctionalityBug.
I still stand by my original reasoning from the original bug report.
I listed this as high severity as it is a flaw that would affect most users and would cause major problems for users. As a dog business owner, i am likely to deal with many regular clients who would like to enrol their dogs to many different programs. Moreover there is a very high likelihood that these owners change the programs that their dogs are enrolled to every now and then. Thus, take the case that I have a long list of programs I want to add a clients dog to.
While I am doing this, the client is likely to be nearby waiting for me to make the necessary changes. As I use the "enrol d/2 p/3 p/4 p/5 p/6 p/7" command, I suddenly get the error that "Dog has already been enrolled in one or more programs.". However, with the error message I am not told which programs the dog has already been enrolled in. This then requires me, as a busy dog school owner, to debug which program the dog has been enrolled to, while the customer waits for me. This poses a major inconvenience to me as a user, as well as my customers.
I think there could have been 2 solutions to this that could have been implemented by the Dev Team.
Firstly, I think the program(s) the dog had already been enrolled in should be clearly displayed in the error message, such that I would not have to debug one-by-one to find out which program the dog has been enrolled to, that is causing this problem.
Secondly, if the dog had already been enrolled in that program and I had included that program, it would not be wrong to allow the operation or even ask for a confirmation from the user, as it will not affect the integrity of the data, as the programs that I want to add the dog to, have already been enrolled in.
Thus in my opinion, this should be a High severity feature flaw. At the very least it should be of medium severity. This is because it would affect most dog school owners in the long run, as they are likely to deal with frequent program enrolment requests from the customer, and the situation described above would likely occur when a customer has to wait around while the dog school owner uses the application.
Unable to enrol a dog to multiple programs when it has been enrolled in one of the programs specified in the parameter.
Expected: The operation to succeed in enrolling the dog 12 to program 10 as expected.
Actual: The dog 12 couldn't be enrolled to program 10 because it was previously enrolled in program 6.
I listed this as high severity as it is a flaw that would affect most users and would cause major problems for users. Take the case that I have a long list of programs I want to add a dog to. I would not know which program the dog has already been added to requiring me as a user to debug which program is causing this issue.
Although the UG states that "Dog must not be enrolled in the program." I think it should be displayed to the user which program the dog had already been enrolled in.
If the dog had already been enrolled in that program and I included that program, it would not be wrong to allow the operation, as it does not affect the integrity of any data at all.
Screenshots: