launchpad-dev team mailing list archive

[Stuart Bishop <stuart.bishop@xxxxxxxxxxxxx>]

> On Tue, Aug 11, 2009 at 12:57:28PM -0300, Guilherme Salgado wrote:
>> 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.

Please don't abuse the data model :-P If you do that, the alerts that
have been setup to detect this data corruption will go off. There
should be foreign key constraints to ensure that all these links
remain sane, and it is unfortunate that we cannot use them due to our
replication requirements.

The way we designed this situation to be handled is you create the
person record and link it to the existing emailaddress and account if
they exist.

If we need to differentiate Person records created through these
automatic approaches (imports from external bug trackers, pofile
imports, branch imports, mailing list imports) from Person records
being actively used, we should add flags. We should not extend the
meaning of creation_rationale - new flags and fields is better. I
certainly don't want to turn it into a bitmap field that makes it
impossible to query sanely.

I guess the main reason we want to differentiate users who have
actively created a Launchpad Person from the import created Person is
so we don't spam people who haven't signed up themselves (which would
happen if someone subscribed them to a bug. I think an 'acivated' or
'deactivated' boolean would handle this - do we need something more
complex than this?

We should certainly create the Person records with a specific
creation_rationale.

We should certainly set the hide-emailaddress flag.


-- 
Stuart Bishop <stuart@xxxxxxxxxxxxxxxx>
http://www.stuartbishop.net/