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 <[email protected]>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
