launchpad-dev team mailing list archive

[Guilherme Salgado <salgado@xxxxxxxxxxxxx>]

On Mon, 2009-08-10 at 16:56 -0300, Christian Robottom Reis wrote:
> On Mon, Aug 10, 2009 at 06:29:43PM +0200, Danilo Šegan wrote:
> > 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.
> 
> Won't this happen in a wide range of situations -- essentially anywhere
> where we are attempting to create Persons lazily where there are
> existing Accounts?
> 
> > 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
> > 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
> 
> Uhm.. I think I understand -- essentially because Rosetta wants to
> credit a translation to a Person, and in this case we need to create one
> and match it with an Account that already exists. But this is a curious
> situation to me:
> 
>     - The Account itself has already been created, so it should already
>       have its own creation rationale, right?
> 
>     - Why does recording the Person's creation rationale matter? Or is
>       the issue more that if there is a Person record then we assume
>       that the person uses Launchpad?
> 
> > Salgado wanted more discussion on the topic on list, and it'd be nice to
> > come up with a suitable workaround, and if we can come up with one
> > that's cherrypickable, even better.
> 
> It seems odd that we have this situation, where parts of the Launchpad
> application are happy to work directly with Accounts and other parts
> require Persons. Is it just that OpenID and ShipIt are special in this
> sense, and that the rest of Launchpad is all engineered around Person?
> 
> If so, then a DB patch uses_launchpad would make sense and I'm sure we
> could get it in this cycle. 

That'd be the ideal solution, but it'd mean a bit of work as there a few
actions that should cause uses_launchpad to change. We'd also have to
change the DB views for valid people/teams to use the new column.

Another (simpler) option is to abuse the fact that the Person and
Account tables are not linked by foreign keys and create the Person
entry when needed but not link it to the existing Account. That way,
everything would just magically work as the Person would seem to have no
account. The only thing we'd have to do is change the registration/login
(maybe reset password too) process to link the Person to the Account
when they are not linked. Of course, by doing that we would also be
hiding any bugs that might cause associated Person/Account entries to
not be linked when they should.

> But I ask myself, would there be Person
> records that had no accompanying Account records? 

Yes, these are the auto-created ones.

> Because that's what I
> think would be correct modeling for this situation -- nobody actually
> created an account, right?

I don't see what you mean by "nobody actually created an account,
right?".

-- 
Guilherme Salgado <salgado@xxxxxxxxxxxxx>

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