user.preferredemail shouldn't be None

<henninge> sinzui: I am trying to triage bug 462891
<henninge> sinzui: the oops happens when trying to access user/preferredemail/email
<sinzui> it is not visible
<sinzui> the app genuinely does not have permission to see it
<henninge> sinzui: does that happen when the user hides his/her email address?
<henninge> sinzui: although I tried that and it did not reproduce
<sinzui> henninge: Yes. In many mail/login usage, we use something link removeSecurityProxy(user.preferredemail).email
<sinzui> henninge: in this tales example. we simply do not have permission to show it. we should not
<henninge> sinzui: ok
<henninge> sinzui: is there an easy way to check in tales if we have that permission of not?
<sinzui> |nothing helps
<sinzui> it swallows exceptions
<henninge> sinzui: good idea, thanks
<sinzui> henninge: in tales you might also do
<sinzui> <tal:visible-email
<sinzui> condition="context/owner/preferredemail/required:launchpad.View">
<sinzui> (<span tal:replace="context/owner/preferredemail/email" />)
<sinzui> </tal:visible-email>
<henninge> sinzui: cool, thanks

I have not been able to reproduce the bug yet. In the two oopses, the users have their email addresses hidden, so I guess that might have something to do with it. I tried it out but there must be other conditions, too.

Since it does not reproduce easily, I am setting it to 'Low' as not many users will be affected.

Let's watch if it occurs very often.

There are a lot more occurances, so it seems to be a bigger problem.

All affected users that I could make out from the oops reports had their email addresses hidden. Some where redirected directly from +newaccount. Could it be a race condition between master and slave db after setting/changing email settings? I am just guessing wildly here.

Raising the importance.

Since we are showing this page to the user who has hidden their email, we should have access to it. We want them to know at what address to expect an email at.

This seems to happen in very weird circumstances: users have just registered, logged in, and went straight away for the download link. Their preferred email address doesn't seem to be in our DB at that point (preferredemail should be accessible to the code, never mind the hidden flag itself).

If we look at the OOPS, we can see that login happens on launchpad_auth_master database, and the error is later on launchpad_main_master DB: how closely are they synced?

We had 46 occurrences on 11/01 and 42 on 11/02, on lpnet. Is this one hard to fix?

It's very interesting that we are seeing this many users experience this. If my assumptions are correct (their accounts are so new, or at least their email confirmations of accounts are so new, that they haven't propagated to our master DB server), it's weird that they start their Launchpad experience with the POTemplate +export page.

Not directly relevant to the bug report, but we should definitely point these new users to better pages to start their Launchpad experience at.

Added a LP Foundations task as well. Branch lp:~danilo/launchpad/bug-462891 provides a generic implementation of preferredemail which also reads from the auth store (at least I've been led to believe it does).

The branch that landed for translations (lp:~danilo/launchpad/bug-462891-none) only works around the problem by not displaying an email address if it's None.

This bug was mentioned in db-devel r8648 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel/revision/8648>

Work-around for this specific instance of a problem in Translations has been rolled out. There are a few other potential cases where it can fail in the same way:

$ grep -rl preferredemail/ lib/lp/*/templates
lib/lp/registry/templates/person-portlet-emails.pt
lib/lp/registry/templates/person-editpgpkeys.pt
lib/lp/registry/templates/distributionmirror-review.pt
lib/lp/registry/templates/person-index.pt
lib/lp/registry/templates/person-editemails.pt
lib/lp/registry/templates/person-rdf-contents.pt
lib/lp/translations/templates/pofile-export.pt
lib/lp/translations/templates/translations-export.pt
lib/lp/translations/templates/potemplate-export.pt