Attempting to access to Bug #1352384 returns error ID OOPS-d327e1681116a93315db08247f36bf2b, what should I do now?

I tried to "Link existing bug" and add 1352384 but it reports that I cannot do that either as the bug is private. Makes some sense as I have little way of knowing it is related when I cannot access it.

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

No one bothered to read this question.
No one bothered to answer this question.
Only a bot came through and decided to close it, because of the above.

You are referencing another bug that I have no access to. Unless there is some east for me to see a summary, the affected versions, suggested work around or anything beyond a label it isn't helpful information. The question was, what should I do now. Do I need to add details to both bugs somehow? Raise a new one? Just give up and hope the problem goes away eventually?

Bug #764414 is public, so you should definitely have access to it.
If that is not the case, then please create a new question or raise a bug against Launchpad itself.

I do apologies Manfred, I am sure I was unable to access something last night but I can confirm that I have access to Bug #764414 right now. It does look like my problem. I guess it also answers what I should do next, which is give up.

To summarise things for the future me that ends up here. 4 or 5 years ago the above problem was noticed. Some people discussed what could be done about it. There is some talk about whether is is LaunchPad (LP) or Apport or both at fault. LaunchPad was (or in some cases still is) providing a confusing UI. Various suggestions have been made that look good or helpful but most have not got anywhere as it would be a lot of work, someone else's job, a privacy concern or just create more problems.

A lot of work stems from there needing to be changes in the way that apport generates bugs. Sometimes it marks things private that could be public. It is only a machine though so it cannot judge this and is doing the best thing it can. The hope is that a human will look at what the machine has done, decide if a bug should be public instead of private and updated it. That would cause fewer private bugs which would mean fewer bugs would be marked as duplicates of private ones. Correcting apport might be (or have been) a lot of fun.

LP does not show any data to a user about a private bug. That is a sensible thing to do but it is a shame it did not display some information from day 1 like the summary and possibly the opening post. If everyone knew that Titles/Summaries were public all the time they could have avoided posting sensitive data there. It is too late now to assume that the data in the title is not private now. It sounds like LP does a better job than it use to, you still get a 400 error but there is some explanation about permissions and what to do to get access if you really need it.

Reading through the various related bugs and posts it sounds like package-maintainers are also locked out of some data. Some of this is not necessary as there is a practise of granting them an override so that they can see some (or all?) the private data in bugs (that relate to their packages?).

The fact that apport and LP needed to both change is what could make bits of the problem, someone else's issue to solve.

Related bugs Bug #764414, Bug #434733, Bug# 396406, Bug #943497 I could provide a summary of which one talks about which part of the overall issue but they do overlap and cross reference each other quite a bit. I think I have captured most of it in the above.

Somewhere in all that https://errors.ubuntu.com/ is mentioned. It is touted as an improvement over launchpad in terms of behaviour. However I have never noticed using this site before and when I try to view data on it I get taken back to LaunchPad. It cannot be a replacement as it still uses the old system.

So I will add my few suggestions here and then leave things to carry on. If we can offer those locked out of the private bug nothing else, I would suggest we give them a a First Known Affected Version & Fixed In or Target Release dates. It does not allow the user to know if their bug is or is not a duplicate for sure but it might give them hope that a fix is on its way (or confirm that it is not yet). Some of the meta-data for a bug cannot be private, what is sensitive about a bug(for which you know only the number)'s Status & Dates?

Really I like the suggested shuffling of files some what. I agree the following would add burden to some maintainer but I also think it would provide a better experience over all. It would also give the maintainer a platform to address their users.
If a private bug gets a duplicate assigned to it, force the creation of a public but and reassign both as duplicates of the public one. The public one has to be made by a human as they need to cheery pick the non-sensitive data to present. Apport would need to know to mark future duplicates to the public head bug but other than that it would not need to change. LP would need some way to tell the owner of the current private head bug that they need to make a public one. The downside is that the maintainer has to make 1 new bug with selected data. The up side is that they can record their work arounds, suggestions of helpful diagnostics to gather and other messages to the users who raise duplicates. Maintainers get less work as they get 1 place to post updates about a problem that several people are having. Users get a page they can view, hopefully with helpful information that will let them confirm a duplicate as LP asks.

--

I will mark this as "Problem Solved" but that is a bit of a fib. Someone needs to do quite a bit of work to make users able to see head bugs before the problem is solved. Still, I have been provided with answers to my questions and found the messy background of what is going on. Please do post if I have to the wrong end of some sticks or if this summary becomes out of date. Thank you Manfred for your help.

Thanks Manfred Hampl, that solved my question.