Malone fails to display a bug publically if one of its duplicates is private

[Christian Reis]

Malone fails to display a bug publically if one of its duplicates is private. To verify:
- Create a public bug
- Create a second bug and mark it private
- Dupe second bug to public bug
- Log out
- Visit public bug
You will be asked to log in.

A current example is bug 3436, which is not publicly accessible because its duplicate bug 3438 is private.

[Diogo Matsubara (matsubara)]

I tracked down the problem. It lies on the bug-portlet-duplicate.pt. What would be the correct solution?

1. Should the public bug be marked as a private bug?
This alternative also means that if we mark a private bug a dupe of a public bug that already has any other public bugs pointing to it, all the others should be marked as private too. But what happens if a user marks a private bug a dupe of a public one by mistake? It inadvertently altered the state of the public one to private.

2. Should the public bug be displayed normally but the private one shouldn't be displayed on the duplicate portlet?

I was going for the second solution, but Salgado raised the issue of the first one, so I need some opinions here.

What do you think?

[Matthew Paul Thomas (mpt)]

The public bug should remain public, the private bug should still be shown in the list of duplicates, but the link's title= should be "[private bug]" instead of the bug's summary.

[Guilherme Salgado (salgado)]

> The public bug should remain public, the private bug should still be
> shown in the list of duplicates, but the link's title= should be
> "[private bug]" instead of the bug's summary.

Should we do the same for private bugs in bug listings or only in the
duplicates portlet? I ask because I thought our policy was to not even let
people know about the existence of private bugs.

[Matthew Paul Thomas (mpt)]

The reason it's not okay for a private bug report to appear in search results is because that would let me find out the content of private bug reports, using a script to search progressively larger strings <http://www.squarefree.com/2004/08/14/hidden-search-results-answer>.

The reason it's okay for a private bug report to be linked in a public bug report's list of duplicates is because thanks to the public bug report, the bug itself is already public. That there are duplicates does not need to be kept secret.

The reason it's not okay for a private bug report's *summary* to be presented in a public bug report's list of duplicates is because the private bug report may be private for reasons other than keeping the bug itself secret, e.g. commercial sensitivity.

[Brad Bollenbach (bradb)]

On 12/14/05, Matthew Paul Thomas <email address hidden> wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/2965
>
> Comment:
> The public bug should remain public, the private bug should still be
> shown in the list of duplicates, but the link's title= should be
> "[private bug]" instead of the bug's summary.

And if the user has launchpad.View permission on the
private_bugtask.bug, the title should be the bug title, of course.

Cheers,

--
Brad Bollenbach