nus-pe-script
commented
1 year ago Team's Response
Not in Scope: Your concerns are valid. However, the reason why we opted for delete to be id-based is because we want the delete feature to work on employees not inside a filtered list, and also because index is not unique and changes when sorting according to different fields. Deleting by id is more consistent, and the same goes for other features as well.
The reason why we opt for AB3 way of using index for edit feature is because we also want users to be able to edit the employee id as well. We had concerns on whether using employee id to edit the employee's own id will cause possible bugs, which is why we settled with another form of identification.
Because the feature to delete by index is a missing feature and is less important than the ability to delete an employee, we have decided to classify this as out of scope.
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [ ] I disagree
Reason for disagreement: [replace this with your explanation]
The delete function relies on the EID for delete. (e.g delete EID2023-7890) which is cumbersome to type. A better way to implement the delete function would to rely on the index of the employee in the employee list. Since the edit method is done using the employee's index on the employee list, I do not see why delete has to use the EID instead of the index which will considerably slow down the user as there is no way to copy/paste the EID from the GUI.