user.preferredemail shouldn't be None

Bug #462891 reported by Ursula Junque on 2009-10-28
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself
Данило Шеган

Bug Description

When someone comes directly from email confirmation page to a page that requires access to user.preferredemail (eg. POFile:+export page such as, user.preferredemail can be None if there was not enough time for data from auth DB to be replicated into the master DB.

At the moment, this set up is not present anywhere except on production, so it's impossible to test for this or to even QA it on staging.

OOPS-1396M1512 and OOPS-1396N1653:
  TraversalError: (None, 'email')

Related branches

Hein Mück (heinmueck) wrote :

<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

Henning Eggers (henninge) wrote :

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.

Changed in rosetta:
status: New → Triaged
importance: Undecided → Low
Henning Eggers (henninge) wrote :

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.

Changed in rosetta:
importance: Low → High

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?

Ursula Junque (ursinha) wrote :

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.

Changed in rosetta:
status: Triaged → In Progress
importance: High → Critical
Ursula Junque (ursinha) on 2009-11-05
tags: added: current-rollout-blocker
Changed in rosetta:
status: In Progress → Fix Committed
Changed in rosetta:
importance: Critical → High
summary: - TraversalError on +export
+ user.preferredemail shouldn't be None

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.

description: updated
Changed in launchpad-foundations:
status: New → Fix Committed
tags: added: qa-needstesting

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

Changed in rosetta:
assignee: nobody → Данило Шеган (danilo)
tags: added: qa-ok
removed: qa-needstesting
Changed in launchpad-foundations:
status: Fix Committed → New
Changed in rosetta:
status: Fix Committed → Fix Released
Changed in rosetta:
milestone: none → 3.1.10
Ursula Junque (ursinha) on 2009-11-09
tags: removed: current-rollout-blocker
Gary Poster (gary) on 2010-03-16
Changed in launchpad-foundations:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers