launchpad-dev team mailing list archive

[Guilherme Salgado <salgado@xxxxxxxxxxxxx>]

On Mon, 2009-08-10 at 15:39 -0400, Francis J. Lacoste wrote:
> 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.
> 

IMO, it's the same as if they had not created an account with Canonical.
And that was perceived by some people as a problem in the past, insomuch
that we've fixed it.

> 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.
> 
> 
-- 
Guilherme Salgado <salgado@xxxxxxxxxxxxx>

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