I'm concerned that its a point-fix rather than digging at the heart of the matter; there are multiple ways things (apport, direct filing, also- affects) and all would seem to suffer from dropping-on-the-floor problem.
I'm speculating here but perhaps an ajax also-affects that presented the new values *to be created* during the process would help as much or more, without running into the special casing issues we will with copying the importance and/or status without a UI. (For instance, if you have triage rights, but an existing task is new, what should we default to? And if there are 2 existing tasks, which should we copy from? Should we prefer same-package different series (of the new target) or same- series different package (of the new target), and what if the existing tasks are not visible, or same-package different distro? How wide should the heuristic be?). Or we could help more bugs get triaged, so that driving-to-zero becomes a common default not something requiring special consideration. Or ... this is why I'd like some more bandwidth with Kate to understand the problem more. On a purely minimal technical level, as long as we don't break folk in different contexts doing their own triage, we can certainly tolerate the directly proposed thing, but I *suspect* either of the other things I've touched on would be higher leverage and address the problem. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/777853 Title: Bugs assigned to new targets are easily missed (their default values sort at the end of bug lists) -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
