Editing a bug via email: "affects" shouldn't create a new task unless you ask for it
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Won't Fix
|
Medium
|
Unassigned |
Bug Description
If I edit a bug via an email: affects /products/malone status
accepted ...
a new task should NOT be created if the task named by "affects"
doesn't exist. Particularly given that "affects" is currently
required (though it shouldn't be, but I understand that this is being
fixed) when there is only one task, this is begging for inadvertent
opening of extra tasks.
I've now been bitten at least twice by this where bugs were opened on
launchpad, and I accidentally followed up with "affects /product/
malone ...", which went right ahead and opened a second task. I will
likely do this again the next time I read a bugmail slightly too
quickly to double-check that it had been opened on Malone in the
first place.
To open a new task on a bug, one should use "also affects ...".
Another possible (though not necessarily mutually exclusive) solution
would be to name the "affects" selector to "change", with aliases
"edit" and "modify".
affects /products/malone
Attachment: PGP.sig
Type: application/
name=PGP.sig
URL: http://
Changed in malone: | |
assignee: | nobody → bjornt |
status: | New → Accepted |
Changed in malone: | |
assignee: | Björn Tillenius (bjornt) → nobody |
Changed in launchpad: | |
status: | Triaged → Won't Fix |
I think that the affects command could stay as it is, but we add another command, 'target', 'edit', 'change' or something like that, which only selects an existing bug task, and thus should fail if the path is wrong.
This has quite low priority though, since with the landing of DefaultAffectsT arget, you don't have to use 'affects' that often anymore.