Yes. See, I would have created a new table. That's why I ask first! :)
On Fri, 2007-07-20 at 23:12 +0200, Jacopo Cappellato wrote:
> Hi David (Shere),
>
> I'd say we can store it in the PartyAttribute entity.
>
> For example:
>
> partyId="10000"
> attrName="EBAY_BUYER_ID"
> attrValue="nY+sHZ2PrBmdj6wVnY+sEZ2PrA2dj6wGkYCnDZeHqQ+dj6x9nY+seQ=="
>
> Does it make sense?
>
> Jacopo
>
> David Shere wrote:
> > Somewhere in a party's record would need to be:
> >
> > * eBay buyer id (like "SteeleRubber")
> > * eBay buyer EIASToken, which looks like this: "nY+sHZ2PrBmdj6wVnY
> > +sEZ2PrA2dj6wGkYCnDZeHqQ+dj6x9nY+seQ==". From eBay documentation: "The
> > EIAS value for a given user does not change, even if the user's eBay
> > user name changes. An application stores this value the same way it
> > stores the eBay user name. When making calls that return a User object
> > (which contains both the UserID and EIASToken), the application checks
> > the user ID returned against the one it has stored and changes the
> > stored user ID as necessary.
> >
> > What table would be the best to put this in?
> >
> > Jacopo Cappellato wrote:
> >> Oh great,
> >>
> >> one detail that we have not implemented (and it isn't in our short
> >> term plan) but that it could be rather important is that, when
> >> importing orders, the interface doesn't attempt to find an existing
> >> party id associated to the eBay buyer: right now a new party is always
> >> created everytime a new order/auction is imported.
> >>
> >> It would be great if you could work in this area:
> >>
> >> * implement a mechanism to lookup parties from an eBay buyer
> >> * if the party is found, determine if we need to update its contact
> >> information
> >>
> >> Of course I will take care of reviewing/committing your work and of
> >> course, if you'll need them, to provide suggestions/details.
> >>
> >> Jacopo
>
>
>
