News:

You may pay someone to create your store, or you visit our seminar and become a professional yourself with the silver certification

Main Menu

VM1 to VM2: Single BT entry overwritten instead of new entries being added

Started by mbarry, January 15, 2014, 15:33:43 PM

Previous topic - Next topic

mbarry

VM 2.0.26a
Joomla 2.5.17

Scenario:
      During the Migration process users are ported across to VM2 tables via call to function portUsers()
      portUsers() searches for and creates entries in #__virtuemart_userinfos based on their virtuemart_user_id

Issue:
      On inspection of the #__virtuemart_userinfos Table it was noted that only a single BT (Bill To) entry was being inserted with changing details on every loop through the migration process.
      A single BT entry was being overwritten instead of new entries being added.

Solution:
      Lines 606, 607 and 615 use $user['id'] instead of $user['user_id'].
      $user['id'] is uninitialised resulting in the insertion of the vendor id via the call to $userModel->setId($user['id']) for each BT entry being migrated.

      Change these lines from $user['id'] to $user['user_id'] solves the issue.

Affected files:
      administrator/components/com_virtuemart/helpers/migrator.php  Lines 606, 607 and 615

Milbo

Strange,
we have in the sql above p`.id = `ui`.user_id

So id and user_id should be the same, even it should be the same, if you found some side effects, I take your advice.
Should I fix your bug, please support the VirtueMart project and become a member
______________________________________
Extensions approved by the core team: http://extensions.virtuemart.net/

mbarry

Hi Milbo,

I just reran the debugger over this again and your correct 'id' is included; it gets pulled in as part of .$JUserString.
Not sure what happened when I first came across this.


mbarry

I see why this didn't work for me the first time. In my initial Migration attempt I forgot to bring across the joomla tables (#__users). Obvious now however, when I started this process a month ago it was a steep learning curve.

mbarry

I backed out my change when upgrading to VM 2.0.26d and got bitten by the problem again.

On investigation, it was found that there are entries in the #__vm_user_info (303 entries) table that are not in the #__users (267 entries) table.
Not sure why this was happening suffice to say that our live website was running VM1.1.3  and J1.5.14 until very recently to support the migration I moved to VM1.1.9. and J1.5.25.

So unless I key on 'user_id', bad things happen. In those instances where 'id' is found to be uninitialised, the user_id is set to the current user via $userModel->setId($user['id']).

I was incorrect previously where I stated that only a single BT entry is created. Where the 'id' exists, separate entries are created. Where the 'id' does not exist, each entry as it is processed will overwrite the current users BT data.

This is not an issue for ST entries since the SELECT for ST processing does not JOIN the #__users Table

My previous suggested fix, including Info message to report any issues found, is included below

                               // Check existance of user_id in #__users
            if($user['user_id'] != $user['id']) {
                  
               vmInfo('Warning user_id : '.$user['user_id'].' does not exist in #__users, Address Type : '.$user['address_type'].' name : '.$user['first_name'].' '.$user['last_name']);
            }
            
            if(!empty($user['user_id'])){
               $user['virtuemart_user_id'] = $user['user_id'];
            }

            if(!empty($user['user_email'])){
               $user['email'] = $user['user_email'];
            }

            //$userModel->setUserId($user['id']);
            $userModel->setId($user['user_id']);      //Should work with setId, because only administrators are allowed todo the migration