[TW-1731] 'done' default filter surprisingly wide
Daniel Shahaf on 2015-12-01T06:27:36Z says:
Consider the following sequence:
% task add foo wait:1h
Created task 1.
% task add foo
Created task 2.
% task /foo/
ID Age Description Urg
2 2s foo 0
% task /foo/ done
Completed task 1 'foo'.
Completed task 2 'foo'.
Completed 2 tasks.
The user passed the same filter to next and to done, but a different set of tasks was affected each time. Concretely, I expected my done command to only affect the issues the report showed.
Now, done doesn't know what report the user viewed when she composed her regexp, and hence can't just "use an implicit report.X.filter filter, with X being the report the user was looking at". So perhaps done should present a per-task confirmation prompt, for tasks that were matched not by id or uuid but by regexp?
I'm not sure whether this is a known issue, but I haven't found a similar issue in jira history.
Migrated metadata:
Created: 2015-12-01T06:27:36Z
Modified: 2016-01-11T19:48:54Z
Daniel Shahaf on 2015-12-01T07:54:59Z says:
This isn't specific to done; the argument for confirmation prompts might be applicable to other commands, e.g., modify, as well.
This is working as designed, I think. The next report has the default filter of status:pending -WAITING limit:page -- waiting tasks, completed tasks, and deleted tasks are explicitly excluded. done is a command, not a report, so has no such exclusion.
It is an unexpected UX, though. I wonder if the filter from the default report should be applied by default to most commands?
I wonder if the filter from the default report should be applied by default to most commands?
That would be unexpected for people that knew that there was a default.command and knew that next was a report, that had a filter.
verbose=filter probably shows this happening and looks like it's included in verbose=on. Furthermore a default filter can be added using context variables. There should probably not be a default filter in the absence of specifying one though...