nus-se-script
commented
9 months ago Team's Response
Bug #4848
Thank you for your bug report.
While we do recognise the improvement and merit of separating the findTask into the two categories, we found it sufficient to implement the feature as such for this milestone and the module requirements.
Introducing this feature would require significant restructuring of the existing search functionality. This involves not only development time but also extensive testing to ensure it integrates seamlessly with other features.
This also would have taken up valuable time and resources that could have been used to implement other more important features, such as the addition of aliases to all commands.
Hence, we believe that this feature is of lower priority compared to what we had to implement by v1.4, so this issue is not in scope.
We hope that you understand our decision. Thank you.
- Response: Not in scope
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [ ] I disagree
Reason for disagreement: [replace this with your explanation]
As of this implementation, findTask returns according to if the keyword was found in the Notes or in the Title. This defeats the purpose of findTask (to quickly locate a specific task, as stated in the UG). As such, a better implementation would have been to make the user enter a prefix, followed by the keyword. For example, to findTask by title, user should input findTask T/ tennis, if they wish to find a task with the title tennis. While a seemingly small issue at small scale, when there are many tasks (1000+), this introduces much more unnecessary responses.