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
