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
