launchpad-dev team mailing list archive

["Francis J. Lacoste" <francis.lacoste@xxxxxxxxxxxxx>]

Hello,

Why don't we simply create a Person and link it to the existing account? Do we 
really need to register that the user never actually register explicitely on 
Launchpad. They did create an account with Canonical.

We should create the Person record with hide_email_address to true, so that 
their email address isn't displayed on Launchpad.


On August 10, 2009, Guilherme Salgado wrote:
> 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.


-- 
Francis J. Lacoste
francis.lacoste@xxxxxxxxxxxxx

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