All migrated orders have current date and are created by admin

[Denitz]

Is this a correct behavior?

[Denitz]

Same for all orders history: all records time is time of migration and creator is admin.

So 'created_on', 'created_by', 'modified_on', 'modified_by' database columns for orders and orders histories always receive current time and current user, not the time and user of old VM records.

[Denitz]

Another issue - migrator::storeMigrationProgress() can fail because of unescaped data, i.e.:

Code Select Expand

storeMigrationProgress failed to update query UPDATE `#__virtuemart_migration_oldtonew_ids` SET `orders`="a:237:{i:1;s:1:"1";i:2;s:1:"2";i:3;s:1:"3";i:4;s:1:"4";i:5;s:1:"5";i:6;s:1:"6";i:7;s:1:"7";i:8;s:1:"8";i:9;s:1:"9";i:10;s:2:"10";i:11;s:2:"11";i:12;s:2:"12";i:13;s:2:"13";i:14;s:2:"14";i:15;s:2:"15";i:16;s:2:"16";i:17;s:2:"17";i:18;s:2:"18";i:19;s:2:"19";i:20;s:2:"20";i:21;s:2:"21";i:22;s:2:"22";i:23;s:2:"23";i:24;s:2:"24";i:25;s:2:"25";i:26;s:2:"26";i:27;s:2:"27";i:28;s:2:"28";i:29;s:2:"29";i:30;s:2:"30";i:31;s:2:"31";i:32;s:2:"32";i:33;s:2:"33";i:34;s:2:"34";i:35;s:2:"35";i:36;s:2:"36";i:37;s:2:"37";i:38;s:2:"38";i:39;s:2:"39";i:40;s:2:"40";i:41;s:2:"41";i:42;s:2:"42";i:43;s:2:"43";i:44;s:2:"44";i:45;s:2:"45";i:46;s:2:"46";i:47;s:2:"47";i:48;s:2:"48";i:49;s:2:"49";i:50;s:2:"50";i:51;s:2:"51";i:52;s:2:"52";i:53;s:2:"53";i:54;s:2:"54";i:55;s:2:"55";i:56;s:2:"56";i:57;s:2:"57";i:58;s:2:"58";i:59;s:2:"59";i:60;s:2:"60";i:61;s:2:"61";i:62;s:2:"62";i:63;s:2:"63";i:64;s:2:"64";i:65;s:2:"65";i:66;s:2:"66";i:67;s:2:"67";i:68;s:2:"68";i:69;s:2:"69";i:70;s:2:"70";i:71;s:2:"71";i:72;s:2:"72";i:73;s:2:"73";i:74;s:2:"74";i:75;s:2:"75";i:76;s:2:"76";i:77;s:2:"77";i:78;s:2:"78";i:79;s:2:"79";i:80;s:2:"80";i:81;s:2:"81";i:82;s:2:"82";i:83;s:2:"83";i:84;s:2:"84";i:85;s:2:"85";i:86;s:2:"86";i:87;s:2:"87";i:88;s:2:"88";i:89;s:2:"89";i:90;s:2:"90";i:91;s:2:"91";i:92;s:2:"92";i:93;s:2:"93";i:94;s:2:"94";i:95;s:2:"95";i:96;s:2:"96";i:97;s:2:"97";i:98;s:2:"98";i:99;s:2:"99";i:100;s:3:"100";i:101;s:3:"101";i:114;s:3:"114";i:115;s:3:"115";i:116;s:3:"116";i:117;s:3:"117";i:118;s:3:"118";i:119;s:3:"119";i:120;s:3:"120";i:121;s:3:"121";i:122;s:3:"122";i:123;s:3:"123";i:124;s:3:"124";i:125;s:3:"125";i:126;s:3:"126";i:127;s:3:"127";i:128;s:3:"128";i:129;s:3:"129";i:130;s:3:"130";i:131;s:3:"131";i:132;s:3:"132";i:133;s:3:"133";i:134;s:3:"134";i:135;s:3:"135";i:136;s:3:"136";i:137;s:3:"137";i:138;s:3:"138";i:139;s:3:"139";i:140;s:3:"140";i:141;s:3:"141";i:142;s:3:"142";i:143;s:3:"143";i:144;s:3:"144";i:145;s:3:"145";i:146;s:3:"146";i:147;s:3:"147";i:148;s:3:"148";i:149;s:3:"149";i:150;s:3:"150";i:151;s:3:"151";i:152;s:3:"152";i:153;s:3:"153";i:154;s:3:"154";i:155;s:3:"155";i:156;s:3:"156";i:157;s:3:"157";i:158;s:3:"158";i:159;s:3:"159";i:160;s:3:"160";i:161;s:3:"161";i:162;s:3:"162";i:163;s:3:"163";i:164;s:3:"164";i:165;s:3:"165";i:166;s:3:"166";i:167;s:3:"167";i:168;s:3:"168";i:169;s:3:"169";i:170;s:3:"170";i:171;s:3:"171";i:172;s:3:"172";i:173;s:3:"173";i:174;s:3:"174";i:175;s:3:"175";i:176;s:3:"176";i:177;s:3:"177";i:178;s:3:"178";i:179;s:3:"179";i:180;s:3:"180";i:181;s:3:"181";i:182;s:3:"182";i:183;s:3:"183";i:184;s:3:"184";i:185;s:3:"185";i:186;s:3:"186";i:187;s:3:"187";i:188;s:3:"188";i:189;s:3:"189";i:190;s:3:"190";i:191;s:3:"191";i:192;s:3:"192";i:193;s:3:"193";i:194;s:3:"194";i:195;s:3:"195";i:196;s:3:"196";i:197;s:3:"197";i:198;s:3:"198";i:199;s:3:"199";i:200;s:3:"200";i:201;s:3:"201";i:202;s:3:"202";i:203;s:3:"203";i:204;s:3:"204";i:205;s:3:"205";i:206;s:3:"206";i:207;s:3:"207";i:208;s:3:"208";i:209;s:3:"209";i:210;s:3:"210";i:211;s:3:"211";i:212;s:3:"212";i:213;s:3:"213";i:214;s:3:"214";i:215;s:3:"215";i:216;s:3:"216";i:217;s:3:"217";i:218;s:3:"218";i:219;s:3:"219";i:220;s:3:"220";i:221;s:3:"221";i:222;s:3:"222";i:223;s:3:"223";i:224;s:3:"224";i:225;s:3:"225";i:226;s:3:"226";i:227;s:3:"227";i:228;s:3:"228";i:229;s:3:"229";i:230;s:3:"230";i:231;s:3:"231";i:232;s:3:"232";i:233;s:3:"233";i:234;s:3:"234";i:235;s:3:"235";i:236;s:3:"236";i:237;s:3:"237";i:238;s:3:"238";i:239;s:3:"239";i:240;s:3:"240";i:241;s:3:"241";i:242;s:3:"242";i:243;s:3:"243";i:244;s:3:"244";i:245;s:3:"245";i:246;s:3:"246";i:247;s:3:"247";i:248;s:3:"248";i:249;s:3:"249";}" , orders_start = "237" WHERE `id` = "1"


The correct method is:

Code Select Expand

$q = 'UPDATE `#__virtuemart_migration_oldtonew_ids` SET `'.$group.'`='.$this->_db->quote(serialize($array)).' '.$limit.' WHERE `id` = "1"';

[manburg6]

Same issues for me... all migrated order with migration date and created by admin.

Ciao,
M.

[manburg6]

Any news about this issue?

Thanks,
Mario

[Jason Farmer]

order_number is similarly lost in the migration.

Product_id's and order_id's have new values? Was this really necessary... why not preserve them? This unnecessary change breaks old links and makes it hard to fix simple problems like creation dates etc. Why is the the migration ids table not simply (type char(1), old_id int(11), new_id int(1))  rather than what is effectively a flat file or 4.

What am I supposed to do with this...
a:586:{i:90126;i:1;i:90127;i:2;i:90128;i:3;i:90129;i:4;i:90132;i:5;i:90133;i:6;i:90134;i:7;i:90135;i:8;i:90138;i:9;i:90139;i:10;i:90141;i:11;i:90142;i:12;i:90148;i:13;i:90149;i:14;i:90150;i:15;i:90151;i:16;i:90152;i:17;i:90153;i:18;i:90154;i:19;i:90155;i:20;i:90170;i:21;i:90172;i:22;i:90173;i:23;i:90174;i:24;i:90175;i:25;i:90178;i:26;i:90179;i:27;i:90182;i:28;i:90183;i:29;i:90184;i:30;i:90186;i:31;i:90188;i:32;i:90193;i:33;i:90194;i:34;i:90195;i:35;i:90196;i:36;i:90198;i:37;i:90199;i:38;i:90202;i:39;i:90204;i:40;i:90206;i:41;i:90207;i:42;i:90208;i:43;i:90209;i:44;i:90214;i:45;i:90215;i:46;i:90216;i:47;i:90218;i:48;i:90219;i:49;i:90220;i:50;i:90223;i:51;i:90225;i:52;i:90226;i:53;i:90227;i:54;i:90228;i:55;i:90231;i:56;i:90232;i:57;i:90234;i:58;i:90235;i:59;i:90236;i:60;i:90237;i:61;i:90238;i:62;i:90239;i:63;i:90240;i:64;i:90241;i:65;i:90242;i:66;i:90243;i:67;i:90245;i:68;i:90246;i:69;i:90247;i:70;i:90248;i:71;i:90249;i:72;i:90250;i:73;i:90252;i:74;i:90253;i:75;i:90254;i:76;i:90255;i:77;i:90261;i:78;i:90262;i:79;i:90263;i:80;i:90264;i:81;i:90266;i:82;i:90268;i:83;i:90270;i:84;i:90271;i:85;i:90272;i:86;i:90280;i:8 etc etc etc

[Jason Farmer]

Detonate the Blobs! 

Using SQL...

Code Select Expand


/*  if your 'orders' blob looks like this...
a:586:{i:90126;i:1;i:90127;i:2;i:90128;i:3;i:90129;i:4;i:90132;i:5;i:90133;i:6;i:90134;i:7;i:90135;i:8;i:90138;i:9;i:90139;i:10;i:90141;i:11;i:90142;i:12;i:90148;i:13;i:90149;i:14;i:90150;i:15;i:90151;i:16;i:90152;i:17;i:90153;i:18;i:90154;i:19;i:90155;i:20;i:90170;i:21;i:90172;i:22;i:90173;i:23;i:90174;i:24;i:90175;i:25;i:90178;i:26;i:90179;i:27;i:90182;i:28;i:90183;i:29;i:90184;i:30;i:90186;i:31;i:90188;i:32;i:90193;i:33;i:90194;i:34;i:90195;i:35;i:90196;i:36;i:90198;i:37;i:90199;i:38;i:90202;i:39;i:90204;i:40;i:90206;i:41;i:90207;i:42;i:90208;i:43;i:90209;i:44;i:90214;i:45;i:90215;i:46;i:90216;i:47;i:90218;i:48;i:90219;i:49;i:90220;i:50;i:90223;i:51;i:90225;i:52;i:90226;i:53;i:90227;i:54;i:90228;i:55;i:90231;i:56;i:90232;i:57;i:90234;i:58;i:90235;i:59;i:90236;i:60;i:90237;i:61;i:90238;i:62;i:90239;i:63;i:90240;i:64;i:90241;i:65;i:90242;i:66;i:90243;i:67;i:90245;i:68;i:90246;i:69;i:90247;i:70;i:90248;i:71;i:90249;i:72;i:90250;i:73;i:90252;i:74;i:90253;i:75;i:90254;i:76;i:90255;i:77;i:90261;i:78;i:90262;i:79;i:90263;i:80;i:90264;i:81;i:90266;i:82;i:90268;i:83;i:90270;i:84;i:90271;i:85;i:90272;i:86;i:90280;i:8 etc etc etc */
/* then this may work for you*/
/* cats, manus, mfcats, shoppergroups,products,orders */
/* 1     2      3       4             5        6 */
DELIMITER $$
DROP PROCEDURE IF EXISTS fixMigrate$$
CREATE PROCEDURE fixMigrate()
BEGIN
DECLARE blobby longblob;
DECLARE intBlob, x, intPos, intLen, intStart, intOld, intNew  INT;
DECLARE strMsg, strChar1, strChar2, strOld, strNew  VARCHAR(255);

DROP TABLE IF EXISTS results;
CREATE TEMPORARY TABLE results (msg varchar(255)) ;
DROP TABLE IF EXISTS jos_vm_migrate_categories;
DROP TABLE IF EXISTS jos_vm_migrate_manufacturers;
DROP TABLE IF EXISTS jos_vm_migrate_manufacturercategories;
DROP TABLE IF EXISTS jos_vm_migrate_shoppergroups;
DROP TABLE IF EXISTS jos_vm_migrate_products;
DROP TABLE IF EXISTS jos_vm_migrate_orders;
CREATE TABLE jos_vm_migrate_categories (category_id INT(11), virtuemart_category_id INT(1), PRIMARY KEY (category_id), KEY `idx_migrate_category_id` (virtuemart_category_id));
CREATE TABLE jos_vm_migrate_manufacturers (manufacturer_id INT(11), virtuemart_manufacturer_id INT(1),PRIMARY KEY (manufacturer_id), KEY `idx_migrate_manufacturer_id` (virtuemart_manufacturer_id));
CREATE TABLE jos_vm_migrate_manufacturercategories (mfcategory_id INT(11), virtuemart_manufacturercategories_id INT(1),PRIMARY KEY (mfcategory_id), KEY `idx_migrate_manufacturercategories_id` (virtuemart_manufacturercategories_id));
CREATE TABLE jos_vm_migrate_shoppergroups (shoppergroup_id INT(11), virtuemart_shoppergroup_id INT(1),PRIMARY KEY (shoppergroup_id), KEY `idx_migrate_shoppergroup_id` (virtuemart_shoppergroup_id));
CREATE TABLE jos_vm_migrate_products (product_id INT(11), virtuemart_product_id INT(1),PRIMARY KEY (product_id), KEY `idx_migrate_product_id` (virtuemart_product_id));
CREATE TABLE jos_vm_migrate_orders (order_id INT(11), virtuemart_order_id INT(1),PRIMARY KEY (order_id), KEY `idx_migrate_order_id` (virtuemart_order_id));
SET intBlob=1;
WHILE intBlob <7 DO
    CASE intBlob
        WHEN 1 THEN
            SELECT cats INTO blobby FROM jos_virtuemart_migration_oldtonew_ids;
            insert into results values("Starting....cats");
        WHEN 2 THEN
            SELECT manus INTO blobby FROM jos_virtuemart_migration_oldtonew_ids;
            insert into results values("Starting....manus");
        WHEN 3 THEN
            SELECT mfcats INTO blobby FROM jos_virtuemart_migration_oldtonew_ids;
            insert into results values("Starting....mfcats");
        WHEN 4 THEN
            SELECT shoppergroups INTO blobby FROM jos_virtuemart_migration_oldtonew_ids;
            insert into results values("Starting....shoppergroups");
        WHEN 5 THEN
            SELECT products INTO blobby FROM jos_virtuemart_migration_oldtonew_ids;
            insert into results values("Starting....products");
        WHEN 6 THEN
            SELECT orders INTO blobby FROM jos_virtuemart_migration_oldtonew_ids;
            insert into results values("Starting....orders");
    END CASE;
       
    SET intLen=0;
    SET x = 1;
    SET strMsg =  '';
   
    set intLen=length(blobby);
    SET intPos=LOCATE("{",blobby);
    insert into results values(Concat("Stripped first ",intPos," chars :",quote(substring(blobby,1,intPos))));
    set intStart = intPos+1;
    /*   */
    set intPos = LOCATE(":",blobby,intStart) ;
    WHILE intPos > 0 AND intPos IS NOT NULL DO
    /* expecting a single char followed by :  ... could do some error checking...*/
       
        set strChar1=substring(blobby,intStart,intPos-intStart);
        set intStart=intPos+1;
        set intPos=  LOCATE(";",blobby,intStart);
        set strOld=substring(blobby,intStart,intPos-intStart);
        set intStart=intPos+1;
        set intPos=  LOCATE(":",blobby,intStart);
        set strChar2=substring(blobby,intStart,intPos-intStart);
        set intStart=intPos+1;
        set intPos=  LOCATE(";",blobby,intStart);
        set strNew=substring(blobby,intStart,intPos-intStart);
        set intStart=intPos+1;
        set intPos=  LOCATE(":",blobby,intStart);
        set intOld=strOld;
        set intNew=strNew;
        insert into results values(concat("#",x,"\t",strChar1,":\t",intOld,";\t",strChar2,":\t",intNew,";"));
        CASE intBlob
            WHEN 1 THEN insert into jos_vm_migrate_categories values (intOld,intNew);
            WHEN 2 THEN insert into jos_vm_migrate_manufacturers values (intOld,intNew);
            WHEN 3 THEN insert into jos_vm_migrate_manufacturercategories values (intOld,intNew);
            WHEN 4 THEN insert into jos_vm_migrate_shoppergroups values (intOld,intNew);
            WHEN 5 THEN insert into jos_vm_migrate_products values (intOld,intNew);
            WHEN 6 THEN insert into jos_vm_migrate_orders values (intOld,intNew);
        END CASE;
        SET  x = x + 1;
    END WHILE;
    set intBlob=intBlob+1;
END WHILE;
insert into results values("Finished ....");
select * from results;
END $$
DELIMITER ;
CALL fixMigrate();

This creates a table for each of the blobs I had (i didn't have any catsxref....) with old id, new id
Then you can issue some more SQL to update those order dates ...

Code Select Expand

create table bak_virtuemart_orders as select * from jos_virtuemart_orders;
update jos_virtuemart_orders  n, jos_vm_migrate_orders x, jos_vm_orders o
set n.order_number = o.order_number,
n.created_on=from_unixtime(cdate),
n.modified_on=from_unixtime(mdate)
where n.virtuemart_order_id = x.virtuemart_order_id
and x.order_id = o.order_id ;

[Jason Farmer]

SQL to fix dates on order history. Dependent on running the SQL in previous post first...

Code Select Expand

DELIMITER $$

DROP PROCEDURE IF EXISTS CreateMigrateOrderHistory$$
CREATE PROCEDURE CreateMigrateOrderHistory()
MAIN: BEGIN
     DECLARE  intCount,intCountItem,intEnd, intAllDone, intMin, intEndOld,intEndNew, intOld,intNew,intOffset,intOldItem, intNewItem INT DEFAULT 0;
     DECLARE  dtCreated_on,dtModified_on datetime;
     DECLARE  cXref         CURSOR FOR SELECT order_id,virtuemart_order_id FROM jos_vm_migrate_orders;
     DECLARE  CONTINUE HANDLER FOR NOT FOUND SET  intEnd = 1;
     
     /* for  loggging information */
     DROP TABLE IF EXISTS results;
     CREATE  TABLE results (
     Id int(11) NOT NULL AUTO_INCREMENT,
     Msg varchar(255) NOT NULL,
     PRIMARY KEY (Id)
     );
     
    DROP TABLE IF EXISTS jos_vm_migrate_order_histories;
    CREATE TABLE jos_vm_migrate_order_histories (order_status_history_id INT(11), virtuemart_order_history_id INT(1),PRIMARY KEY (order_status_history_id), KEY `idx_migrate_order_history_id` (virtuemart_order_history_id));

    INSERT  INTO results(msg) VALUES  ("Starting ... looking for order items");
    SET intCount=1;
    OPEN  cXref;

    FETCH cXref INTO intOld, intNew;

    WHILE intEnd=0 DO
        INSERT  INTO results(msg) VALUES  (CONCAT("#",intCount,"   ",intNew,"--->",intOld, " "));
        HISTORY: BEGIN
            /*
            order histories and order items all have new ids that are not referenced by migrate tables...
            create a migrate table for them? or sort them out now?
            just create the migrate table ... too long a transaction otherwise, and the update afterwards using the join is quick and easy in any case.
            */
           
            /* open two ordered cursors and step through each table (old and new) ... matching them up as I go... */
            DECLARE  intCountItem, intEndInner,intEndOld,intEndNew,intOldItem, intNewItem INT DEFAULT 0;
            DECLARE  dtCreated_on datetime;
            DECLARE  cOldHistory   CURSOR FOR
                SELECT  order_status_history_id,
                        date_added
                FROM jos_vm_order_history
                where order_id=intOld
                order by order_status_history_id ;
            DECLARE  cNewHistory   CURSOR FOR
                SELECT virtuemart_order_history_id
                FROM jos_virtuemart_order_histories
                where virtuemart_order_id=intNew
                order by virtuemart_order_history_id;
            DECLARE  CONTINUE HANDLER FOR NOT FOUND SET  intEndInner = 1;

            OPEN  cOldHistory;
            OPEN  cNewHistory;
            SET intCountItem=1;
            SET intEndInner=0;
            SET intEndNew=0;
            SET intEndOld=0;
           
            FETCH cOldHistory INTO intOldItem, dtCreated_on;
            IF intEndInner=1 THEN
                SET intEndInner=0;
                SET intEndOld=1;
            END IF;
            FETCH cNewHistory INTO intNewItem;
            IF intEndInner=1 THEN
                SET intEndInner=0;
                SET intEndNew=1;
            END IF;
           
            WHILE intEndNew=0 AND intEndOld=0 DO
                /* two matched records ... one hopes*/
                INSERT  INTO results(msg) VALUES  (CONCAT("#",intCountItem,"   ",intOld,"   ",intNewItem," = ",intOldItem, " matched History"));
/*                UPDATE jos_virtuemart_order_histories
                    SET created_on=dtCreated_on
                    WHERE virtuemart_order_id=intNew
                    AND virtuemart_order_history_id=intNewItem;*/
                INSERT INTO jos_vm_migrate_order_histories VALUES (intOldItem,intNewItem);
               
                SET intCountItem=intCountItem+1;
                FETCH cOldHistory INTO intOldItem, dtCreated_on;
                IF intEndInner=1 THEN
                    SET intEndInner=0;
                    SET intEndOld=1;
                END IF;
                FETCH cNewHistory INTO intNewItem;
                IF intEndInner=1 THEN
                    SET intEndInner=0;
                    SET intEndNew=1;
                END IF;
            END WHILE;
            CLOSE  cOldHistory;
            CLOSE  cNewHistory;
            IF intEndNew=0 OR intEndOld=0 THEN
                INSERT  INTO results(msg) VALUES  (CONCAT(intOld," Error on History - mismatch occurred!!!"));
            END IF;
        END HISTORY;
       
        SET intCount=intCount+1;
        FETCH cXref INTO intOld, intNew;
    END WHILE;

    CLOSE  cXref;
    SELECT *  FROM results;
    DROP TABLE  results;
END MAIN$$
DELIMITER $$
DROP PROCEDURE IF EXISTS UpdateOrderHistory$$
CREATE PROCEDURE UpdateOrderHistory()
MAIN: BEGIN
    update jos_virtuemart_order_histories n, jos_vm_migrate_order_histories x, jos_vm_order_history o
    set n.created_on=date_added
    where n.virtuemart_order_history_id = x.virtuemart_order_history_id
    and x.order_status_history_id = o.order_status_history_id ;
END MAIN$$

DELIMITER ;
/*CALL RestoreOrders();*/
CALL CreateMigrateOrderHistory();
CALL UpdateOrderHistory();

[xpozay]

I realise this is an old thread but still very relevant to vm 2.0.16d.

Did any of you fix this such that the created_by and modified_by contain the creator of the order (shopper userid) rather than admin / migrator id?  I would simply fix this myself but I am not a coder - but can try patching if somebody can help me with the code.

[xpozay]

I done some preliminary patching but am stuck in one place, if somebody could assist it would be greatly appreciated:
- For orders and order items I have it working ok
- For order history it is still not working.

Note: When running the migrator I am only choosing orders and nothing else.  My intention is to run each item at a time in migrator and then make these changes only when running the migrator on orders.

Changes to vmtable.php
Around line 285 replaced

Code Select Expand

$this->modified_on = $today;
$this->modified_by = $user->id;

With

Code Select Expand

if($this->modified_on=="0000-00-00 00:00:00"){
$this->created_on = $this->$today;
}

Note: I take care of the modified_by in migrator.php

Changes to migrator.php
Around line 1386 after (for virtuemart_orders)

Code Select Expand

$orderData->created_on = $this->_changeToStamp($order['cdate']);
$orderData->modified_on = $this->_changeToStamp($order['mdate']); //we could remove this to set modified_on today


added

Code Select Expand

$orderData->created_by = $order['user_id'];
$orderData->modified_by = $order['user_id'];


Around line 1414 (for order items)
after

Code Select Expand

$item['product_attribute'] = $this->_attributesToJson($item['product_attribute']); //we could remove this to set modified_on today

added

Code Select Expand

$item['created_by'] = $order['user_id'];
$item['modified_by'] = $order['user_id'];


Around line 1433 (for order history - is not working yet)
after

Code Select Expand

$item['virtuemart_order_id'] = $newId;

added

Code Select Expand

$item['created_on'] = $this->_changeToStamp($item['cdate']);
$item['modified_on'] = $this->_changeToStamp($item['cdate']); //we could remove this to set modified_on today
$item['created_by'] = $order['user_id'];
$item['modified_by'] = $order['user_id'];


This last change I am trying to add the dates as well as they are not defined here like the previous tables.

It is only the last change that is not working.  The first two are OK.

Appreciate any help.

Thanks

[xpozay]

Well learning a little anyway.  I have come up with a hack for the order history now.

In migrator.php around line 1432 replace

Code Select Expand

foreach($oldItems as $item){
$item['virtuemart_order_id'] = $newId;
//$item['order_status_code'] = $orderCodeToId[$item['order_status_code']];


$orderHistoriesTable = $this->getTable('order_histories');
$orderHistoriesTable->bindChecknStore($item);
$errors = $orderHistoriesTable->getErrors();
if(!empty($errors)){
foreach($errors as $error){
$this->_app->enqueueMessage('Migration orderhistories: ' . $error);
}
$continue = false;
break;
}
}


with

Code Select Expand

foreach($oldItems as $item){
$historyData = new stdClass();
$historyData->virtuemart_order_id = $newId;
$historyData->created_on = $item['date_added'];
$historyData->modified_on = $item['date_added'];
$historyData->order_status_code = $item['order_status_code'];
$historyData->customer_notified = $item['customer_notified'];
$historyData->comments = $item['comments'];
if($item['order_status_code'] == "P" or $item['order_status_code'] == "C" ){
$historyData->created_by = $order['user_id'];
$historyData->modified_by = $order['user_id'];
}

$orderHistoriesTable = $this->getTable('order_histories');
$orderHistoriesTable->bindChecknStore($historyData);
$errors = $orderHistoriesTable->getErrors();
if(!empty($errors)){
foreach($errors as $error){
$this->_app->enqueueMessage('Migration orderhistories: ' . $error);
}
$continue = false;
break;
}
}


Note:
- This is not 100% full proof.  In VM1 the person making the changes to the order_history table was not tracked, so it is not possible to have 100% of the data copied across.  I looked at VM2 and made a few dummy orders to see what information was stored in the history table.  When the customer does the buying and there is no involvement from the admin / store owner, so the order history data records the shopper user_id.  When the admin / store owner makes a status change eg. confirmed to shipped, the admin user_id is recorded.  This is logical and better than VM1.

So the approach I took above was to make all history records with a status code of "P" or "C" recorded against the shopper.   The rest of the records "X", "R" and "S" recorded against the system admin_id (this is what the migrator was doing for all records).  For me this is pretty logical as:
- the store admin is the one who knows if the product was shipped or not and thus changes the status to shipped
- the store admin executes and refunds and thus changes the status
- most cancellations, in my store, are because of abandoned cart not because the shopper cancels.

I think the above is probably 95%-99% accurate in my shop.  The few mistakes would be for shopper cancellations on their own which I can live with.

The only other thing I needed to do was adjusts vmtable.php again so now I have changed

Code Select Expand

//ADDED BY P2 PETER
if($this->created_on=="0000-00-00 00:00:00"){
$this->created_on = $this->$today;
}
//END ADD

$this->modified_on = $today;
$this->modified_by = $user->id;

to

Code Select Expand

//ADDED BY P2 PETER
if($this->created_on=="0000-00-00 00:00:00"){
$this->created_on = $this->$today;
}
//END ADD

if($this->modified_on=="0000-00-00 00:00:00"){
$this->created_on = $this->$today;
}

if(empty($this->created_by)){
$this->created_by = $user->id;
}


to record the system admin status changes ie Refunded, Canceled, Shipped.

Note:  I use the normal vmtable.php and migrator.php for all migrations except orders.  When I come to orders I change my vmtable.php and migrator.php, run orders and then put back the original files.  This is only because I do not wish to test and see if these changes mess anything else up.  My gut feel is they do not but it is not worth the risk.

[Milbo]

If you have a lot abandoned cart, you should rise your session time.

You should take a look on the oder table, and overwrite there the store function, maybe we can do it so that we can add it to the core, atm,..

good work, but we cannot add it that way

[xpozay]

Thanks for the feedback, a few questions / comments:
- what do you mean by "overwrite the store function"?  Do you mean in the vendor_store? I don't think so?  Do you mean bindcheckstore() or store() ?

Understand what I have done cannot be taken directly, primarily because of the different status codes eg "S", "C", etc.  between each shop/store.  That said I think that:

- Writing the shopper_id, created_on and modified_on can be stored "correctly" to tables virtuemart_order, virtuemart_items instead of the migration date and admin_id.  We have the original cdate and mdate for the orders and order_items thus we should use them.  And it is logical that the orders are created by the shopper too since in VM1 we do not really have the concept of creating orders, by the admin, on behalf of the shopper.

- For virtuemart_histories we know the date_added and thus this can be used for both created_on and modified_on - this is definately logical and more accurate than using the migrator date.  The only doubt is the created_by and modified_by.  IMO it would be more logical (and perhaps more correct) to use the shopper_id when the date of the status change is 'near' to the original order date (cdate).  Still a bit vague and thus perhaps for histories use the admin_id as is done now.    Perhaps, another option would be to give the admin the option when running the migrator.  Include after "Use the vm1 order id as vm2 order number " a new check box to say "User shopper_id as modified_by" for order history.  Thus by default it is the admin_id and for those who want, they can do as described above.

Thanks for the tip about abandoned cart, I shall look into that.