developer advices on synch between vm_userinfos and joomla user_profiles ?

[whisky]

browsing the forum, on the theme 'user profile',
there is no clear solution,since 2011, on the synchronisation of user data between Joomla recommended way of adding user extra fields
aggregated on behalf of all extensions into the commun #__user_profile table.

For example the joomla 'example' user_profile 'plug-in' that is understood by a lot of admins as the way to add 'adresses/country..' data fields
aren't synched properly with VM and led to user experience of customers feeling obliged to fill twice their own data.

Or worst when, you try to be clever on currencies and tax, and deliver a smooth user experience, by geolocating user either from their IP
or by the mean of a standard 'registered user' profile in joomla, that could set the User's country, there is no proper way to tell
vm, where it as no prior knowledge of a 'not yet' known/registered user, that in fact you can provide end-user informations (like country, currency...)

I'v tried to find a proper (and cleaner way, if this latter quality fit in the vm 'ecosystem' ;-)), but I'm wondering if an other
developer has some advices on doing it.

Here is the list of what I'm going to try, if you have better ideas, I'll be glad to exchange for the profit of other folks suffering the same fate.

1) try to add a 'vmuserfield' plug-in as, this type of plug-ins can get triggered with 'plgVmOnBeforeUserfieldSave', 'plgVmPrepareUserfieldDataSave'
    or even by 'plgVmOnUserfieldDisplay' where some fields could be 'forced' with some such external knowledge.
   
2) there is a method that seems to be used a lot by vm developers, consisting of having a wild dispatch at the very beginning of vm controler
  namely having plug-ins ('vmuserfield') implementing the 'plgVmOnMainController' or  'vmextended' type plug-in implementing the 'onVmSiteController' callbacks.
 
  where in this type of code, you could be as dirty as you like (no pointing fingers yet ;-)) and play with the session and card, as you see fit.
  Sound like some 'high end' plugins follows this path.
 
3) when following callflow, I noticed that the #__virtuemart_userinfos could be out of synch with #__virtuemart_users,
   so there could be some user informations (like adresses/country...), while there is not yet a 'vm_user' row.
   Situations where this happend correspond to this strange time window, where the shopper as some known informations from joomla (e.g user profile)
   and virtuemart hasn't yet decided either to create its own 'vm_user' row (or end-user hasn't yet logged but never bought anything yet from vm, so it
   is not known by vm.
   
If you have more thoughts, please don't hesitate to share.

[whisky]

I can confirm the 3) approach work relatively well.

Virtuemat do not enforce referencial integrity on #__virtuemart_users and #__virtuemart_userinfos
so with proper mapping between joomla 'profile' user plug-in (given as an example for Joomla authors)
it is not hard to synchronize Joomla user account to vm corresponding informations.

However, to be complete the synch, should go the other way, from vm to joomla profile
but then, there is a problem as joomla standard table for storing all user added fields (namely the table #__user_profile)
doesn't have a date field, to compare the 'freshness' of data between Joomla and virtuemart.

As this 'helper' is more to facilitate, buying, I guess the joomla -> vm sharing, is the most important one for sellers.

[Milbo]

The userinfo table has no synchronisation to the users.

The joomla users and vmusers table are linked with the same id. We do not use the joomla userfields. There are two reason for that. First they are a new invention, second, just check the joomla fixes in j2.5.19 and you would see that they were not secured.

The best method would be to create a plugin, which gets active storing a joomla user. But atm there is not a big problem. There is just no link between joomla contact information and vm addresses. Joomla user can become vm users and that is done automatically.