nus-pe-bot
commented
2 years ago Team's Response
Rejected. It is the intended behavior, as stated below.
If the task view remains filtered after the assignment, it will be inconvenient for users who want to assign/edit tasks that are not in the filtered list. Moreover, this may confuse them as they may regard the filtered list as the original list. They will not be able to find some tasks, and they may think they're lost. Compared to the scenario provided by the tester (assign multiple tasks in the filtered list), this is more common and should be handled with higher priority.
On the other hand, users can still assign multiple tasks under the current behavior, but if it changes to what the tester suggests, then users who want to manipulate tasks not in the filtered list can't achieve what they want. Therefore, it is better to stick to what we have now.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: I do not agree that it will be more confusing for people, thinking the filtered list is the original list. In fact, I found the current behavior much more confusing as the command is essentially introducing a side effect of returning the filtered task list to the original task list when the only command I gave was to assign a task. If I wanted to return the list to the original list after I assign a task I simply have to type task -l which is relatively simpler than discovering my task list was returned to the original list and having to filter again using in this case task -f Reportbut in certain cases it could be more complicated filter keywords.
Since the team has designed this as an intended feature and not a bug, perhaps that this should be considered as a Feature Flaw instead of a Functionality Bug
After finding tasks by name, assigning task using
task -asresults in the list no longer being filtered as iftask -lwas used. Making it really difficult to use the find command and assign multiple tasks.task -f Reporttask -as 2 1