launchpad-dev team mailing list archive

[Guilherme Salgado <salgado@xxxxxxxxxxxxx>]

On Mon, 2009-08-10 at 18:29 +0200, Danilo Šegan wrote:
> Hi Salgado, all,
> 	
> I've just noticed a problem in our person creation code:
> 
>   https://bugs.edge.launchpad.net/rosetta/+bug/411514
> 
> We are trying to create a Person record to attribute translations to,
> however, since account for the email already exists,
> createPersonAndEmail fails with EmailAddressAlreadyTaken exception.
> 
> This is almost identical to 
> 
>   https://bugs.edge.launchpad.net/launchpad-foundations/+bug/408528
> 
> 
> The problem with blindly creating a Person in these cases is that we are
> using existence of Person record as an indicator that someone has

s/Person/Account

> knowingly registered on Launchpad (as opposed to just using shipit or a
> similar service), so we can't do that without providing an indicator
> that certain Person record was explicitely registered (or activated) or
> if it was just automatically generated through some import.
> 
> To properly fix this, we'd probably provide a new attribute (and DB
> column) on Person objects.  But, without a DB column, we can perhaps
> extend creation_rationale with an element which can be easily split out;
> g. do something like:
> 
>   Person.uses_launchpad = creation_rationale & 0x10000
>   Person.creation_rationale = creation_rationale & 0xffff

I think this would be acceptable as a temporary solution, so that these
newly created entries show up on launchpad.net as placeholder profiles
and we have a way of identifying them later, to do the necessary data
migration when we fix things the proper way.

> 
> Not sure how well this would cope with our DBEnum usage (i.e. form
> writes might lose it if we don't deal properly with it, especially since
> Storm doesn't support setters and getters), but I feel that might be a
> worthwhile workaround otherwise.

I don't think we have any forms that write to the creation_rationale --
it's always changed as a side effect of doing certain operations.

However, doing what's suggested above would involve quite some work as
we'd have to, at least, change the existing validperson*cache DB views
to take into account the special rationale, as well as our
registration/password-reset workflows, so that they change the creation
rationale in case the user registers in LP.

-- 
Guilherme Salgado <salgado@xxxxxxxxxxxxx>

Attachment: signature.asc
Description: This is a digitally signed message part