| 2009-09-22 16:25:28 |
Karl Fogel |
bug |
|
|
added bug |
| 2009-09-22 16:26:32 |
Karl Fogel |
tags |
|
ui |
|
| 2009-10-22 16:31:24 |
Deryck Hodge |
malone: status |
New |
Triaged |
|
| 2009-10-22 16:31:27 |
Deryck Hodge |
malone: importance |
Undecided |
High |
|
| 2011-03-23 23:13:53 |
Curtis Hovey |
tags |
lp-bugs ui |
confusing-ui disclosure lp-bugs privacy ui |
|
| 2011-03-23 23:48:38 |
Robert Collins |
marked as duplicate |
|
262280 |
|
| 2011-03-23 23:49:15 |
Robert Collins |
removed duplicate marker |
262280 |
|
|
| 2011-04-11 14:12:23 |
Curtis Hovey |
tags |
confusing-ui disclosure lp-bugs privacy ui |
404 confusing-ui disclosure lp-bugs privacy regression ui |
|
| 2011-04-11 14:12:29 |
Curtis Hovey |
launchpad: importance |
High |
Critical |
|
| 2011-04-11 21:46:29 |
j.c.sackett |
branch linked |
|
lp:~jcsackett/launchpad/private-bugs-404 |
|
| 2011-04-12 06:26:43 |
Juozas Pocius |
bug |
|
|
added subscriber Juozas Pocius |
| 2011-04-12 13:58:06 |
Curtis Hovey |
tags |
404 confusing-ui disclosure lp-bugs privacy regression ui |
404 chr confusing-ui disclosure lp-bugs privacy regression ui |
|
| 2011-04-16 14:50:53 |
joopbraak |
description |
When a public bug is marked as a duplicate of a private bug, the UI for those who can only see the public bug is confusing. In the public bug, the "Duplicate of bug #NNNNN" text in the upper right (beneath "This report is public") gives the number of the private bug, but is *not* a link.
For the user, this is frustrating. They can see that the public report is a duplicate of something private, but they have no way to see the private thing (fair enough) and no way to ping the owner(s) of the private thing to ask them if it really needs to be private. Maybe it does: if it's an apport filing, for example, it may contain private crash data in the attachment, even though the bug itself is not a security vulnerability.
One solution might be to distinguish between:
1) Bugs that are inherently private, because (say) they are security vulnerabilities.
2) Bugs where the bug itself can be public, but the reproduction data is private.
In case (2), the bug could be public and just the attachment be kept private. As long as the attachment clearly explained why it wasn't public, this would be a vast improvement, both in terms of making more bug information available and in not frustrating users.
Meanwhile, when a public bug is marked as a dup of a (1)-style private bug, then at least the "Duplicate of bug #NNNNN" could be a link to some page that offers some kind of explanation for why you can't see the real bug. That would obviate the need to keep making answers like these:
https://answers.edge.launchpad.net/launchpad/+question/48630
https://answers.edge.launchpad.net/launchpad/+question/48630
See also:
* bug #334130 ("misbehaviour in marking duplicates of a private bug")
* bug #157899 ("Shouldn't need access to private bug report to reverse a public duplicate marking")
Solving this bug would probably solve most of #334130 (this might even be considered a dup of that one, but it's hard to say, as 334130 is partly about the UI for actually marking the dup, whereas this is strictly about the UI for encountering an already-marked dup). |
When a public bug is marked as a duplicate of a private bug, the UI for those who can only see the public bug is confusing. In the public bug, the "Duplicate of bug #NNNNN" text in the upper right (beneath "This report is public") gives the number of the private bug, but is *not* a link.
For the user, this is frustrating. They can see that the public report is a duplicate of something private, but they have no way to see the private thing (fair enough) and no way to ping the owner(s) of the private thing to ask them if it really needs to be private. Maybe it does: if it's an apport filing, for example, it may contain private crash data in the attachment, even though the bug itself is not a security vulnerability.
One solution might be to distinguish between:
1) Bugs that are inherently private, because (say) they are security vulnerabilities.
2) Bugs where the bug itself can be public, but the reproduction data is private.
In case (2), the bug could be public and just the attachment be kept private. As long as the attachment clearly explained why it wasn't public, this would be a vast improvement, both in terms of making more bug information available and in not frustrating users.
Meanwhile, when a public bug is marked as a dup of a (1)-style private bug, then at least the "Duplicate of bug #NNNNN" could be a link to some page that offers some kind of explanation for why you can't see the real bug. That would obviate the need to keep making answers like these:
https://answers.edge.launchpad.net/launchpad/+question/48630
See also:
* bug #334130 ("misbehaviour in marking duplicates of a private bug")
* bug #157899 ("Shouldn't need access to private bug report to reverse a public duplicate marking")
Solving this bug would probably solve most of #334130 (this might even be considered a dup of that one, but it's hard to say, as 334130 is partly about the UI for actually marking the dup, whereas this is strictly about the UI for encountering an already-marked dup). |
|
| 2011-04-18 15:46:05 |
Launchpad QA Bot |
launchpad: milestone |
|
11.05 |
|
| 2011-04-18 15:46:05 |
Launchpad QA Bot |
launchpad: assignee |
|
j.c.sackett (jcsackett) |
|
| 2011-04-18 15:46:09 |
Launchpad QA Bot |
launchpad: status |
Triaged |
In Progress |
|
| 2011-04-18 16:14:47 |
Ursula Junque |
tags |
404 chr confusing-ui disclosure lp-bugs privacy regression ui |
404 chr confusing-ui disclosure lp-bugs privacy qa-untestable regression ui |
|
| 2011-04-19 00:21:56 |
Robert Collins |
launchpad: status |
In Progress |
Triaged |
|
| 2011-04-19 00:21:59 |
Robert Collins |
launchpad: importance |
Critical |
High |
|
| 2011-04-19 00:22:01 |
Robert Collins |
launchpad: assignee |
j.c.sackett (jcsackett) |
|
|
| 2011-04-19 00:22:03 |
Robert Collins |
launchpad: milestone |
11.05 |
|
|
| 2011-04-23 19:03:59 |
Curtis Hovey |
tags |
404 chr confusing-ui disclosure lp-bugs privacy qa-untestable regression ui |
chr confusing-ui disclosure lp-bugs privacy qa-untestable regression ui |
|
| 2011-04-23 19:04:13 |
Curtis Hovey |
tags |
chr confusing-ui disclosure lp-bugs privacy qa-untestable regression ui |
chr confusing-ui disclosure lp-bugs privacy ui |
|
| 2011-06-07 16:14:37 |
Marcel Stimberg |
bug |
|
|
added subscriber Marcel Stimberg |
| 2011-09-11 12:09:02 |
Dmitry Tantsur |
bug |
|
|
added subscriber Dmitry "Divius" Tantsur |
| 2011-09-11 12:39:18 |
Juozas Pocius |
removed subscriber Juozas Pocius |
|
|
|
| 2011-09-11 12:40:41 |
Juozas Pocius |
bug |
|
|
added subscriber Juozas Pocius |
| 2011-09-11 17:30:05 |
Adolfo Jayme Barrientos |
bug |
|
|
added subscriber Fitoschido |
| 2011-09-11 19:33:22 |
Robert Collins |
description |
When a public bug is marked as a duplicate of a private bug, the UI for those who can only see the public bug is confusing. In the public bug, the "Duplicate of bug #NNNNN" text in the upper right (beneath "This report is public") gives the number of the private bug, but is *not* a link.
For the user, this is frustrating. They can see that the public report is a duplicate of something private, but they have no way to see the private thing (fair enough) and no way to ping the owner(s) of the private thing to ask them if it really needs to be private. Maybe it does: if it's an apport filing, for example, it may contain private crash data in the attachment, even though the bug itself is not a security vulnerability.
One solution might be to distinguish between:
1) Bugs that are inherently private, because (say) they are security vulnerabilities.
2) Bugs where the bug itself can be public, but the reproduction data is private.
In case (2), the bug could be public and just the attachment be kept private. As long as the attachment clearly explained why it wasn't public, this would be a vast improvement, both in terms of making more bug information available and in not frustrating users.
Meanwhile, when a public bug is marked as a dup of a (1)-style private bug, then at least the "Duplicate of bug #NNNNN" could be a link to some page that offers some kind of explanation for why you can't see the real bug. That would obviate the need to keep making answers like these:
https://answers.edge.launchpad.net/launchpad/+question/48630
See also:
* bug #334130 ("misbehaviour in marking duplicates of a private bug")
* bug #157899 ("Shouldn't need access to private bug report to reverse a public duplicate marking")
Solving this bug would probably solve most of #334130 (this might even be considered a dup of that one, but it's hard to say, as 334130 is partly about the UI for actually marking the dup, whereas this is strictly about the UI for encountering an already-marked dup). |
When a public bug is marked as a duplicate of a private bug, the UI for those who can only see the public bug is confusing. In the public bug, the "Duplicate of bug #NNNNN" text in the upper right (beneath "This report is public") gives the number of the private bug, but is *not* a link.
For the user, this is frustrating. They can see that the public report is a duplicate of something private, but they have no way to see the private thing (fair enough) and no way to ping the owner(s) of the private thing to ask them if it really needs to be private. Maybe it does: if it's an apport filing, for example, it may contain private crash data in the attachment, even though the bug itself is not a security vulnerability.
Apport deliberately does this - see bug 764414.
One solution might be to distinguish between:
1) Bugs that are inherently private, because (say) they are security vulnerabilities.
2) Bugs where the bug itself can be public, but the reproduction data is private.
In case (2), the bug could be public and just the attachment be kept private. As long as the attachment clearly explained why it wasn't public, this would be a vast improvement, both in terms of making more bug information available and in not frustrating users.
Meanwhile, when a public bug is marked as a dup of a (1)-style private bug, then at least the "Duplicate of bug #NNNNN" could be a link to some page that offers some kind of explanation for why you can't see the real bug. That would obviate the need to keep making answers like these:
https://answers.edge.launchpad.net/launchpad/+question/48630
See also:
* bug #334130 ("misbehaviour in marking duplicates of a private bug")
* bug #157899 ("Shouldn't need access to private bug report to reverse a public duplicate marking")
Solving this bug would probably solve most of #334130 (this might even be considered a dup of that one, but it's hard to say, as 334130 is partly about the UI for actually marking the dup, whereas this is strictly about the UI for encountering an already-marked dup). |
|
| 2011-09-14 14:17:54 |
Curtis Hovey |
tags |
chr confusing-ui disclosure lp-bugs privacy ui |
chr confusing-ui lp-bugs privacy ui |
|
| 2012-02-22 05:38:17 |
Steve Kowalik |
branch linked |
|
lp:~stevenk/launchpad/bug-limitedview |
|
| 2012-02-22 20:40:45 |
Launchpad QA Bot |
launchpad: assignee |
|
Steve Kowalik (stevenk) |
|
| 2012-02-22 20:40:47 |
Launchpad QA Bot |
tags |
chr confusing-ui lp-bugs privacy ui |
chr confusing-ui lp-bugs privacy qa-needstesting ui |
|
| 2012-02-22 20:40:48 |
Launchpad QA Bot |
launchpad: status |
Triaged |
In Progress |
|
| 2012-02-23 03:04:37 |
William Grant |
tags |
chr confusing-ui lp-bugs privacy qa-needstesting ui |
chr confusing-ui lp-bugs privacy qa-untestable ui |
|
| 2012-04-07 22:17:26 |
JohnWashington |
bug |
|
|
added subscriber JohnWashington |
| 2012-06-28 01:29:31 |
Siddhant Saraf |
bug |
|
|
added subscriber Siddhant Saraf |
| 2012-07-25 11:45:05 |
Marius B. Kotsbak |
bug |
|
|
added subscriber Marius Kotsbak |
| 2012-07-25 16:27:03 |
Curtis Hovey |
tags |
chr confusing-ui lp-bugs privacy qa-untestable ui |
bug-links chr confusing-ui lp-bugs privacy qa-untestable ui |
|
| 2012-08-30 02:26:22 |
Edward Donovan |
bug |
|
|
added subscriber Edward Donovan |
| 2012-08-31 13:44:58 |
Curtis Hovey |
launchpad: assignee |
Steve Kowalik (stevenk) |
|
|
| 2012-10-08 04:41:59 |
Curtis Hovey |
launchpad: status |
In Progress |
Triaged |
|
| 2012-10-15 14:39:05 |
Tobiasz Jarczyk |
bug |
|
|
added subscriber Tobiasz Jarczyk |
| 2013-02-25 03:41:21 |
iMac |
removed subscriber iMac |
|
|
|
| 2013-09-17 22:44:49 |
JohnWashington |
bug task added |
|
apport |
|
| 2013-09-17 23:11:22 |
Martin Pitt |
marked as duplicate |
|
764414 |
|
| 2013-09-19 11:17:04 |
Juozas Pocius |
removed subscriber Juozas Pocius |
|
|
|
