CoreBOSBB
Migrate from vtiger 6.3 - Printable Version

+- CoreBOSBB (https://discussions.corebos.org)
+-- Forum: Development (https://discussions.corebos.org/forum-18.html)
+--- Forum: coreBOS Development (https://discussions.corebos.org/forum-4.html)
+---- Forum: coreBOS (https://discussions.corebos.org/forum-5.html)
+---- Thread: Migrate from vtiger 6.3 (/thread-243.html)

Pages: 1 2


RE: Migrate from vtiger 6.3 - joebordes - 02-25-2016

For the configuration I'd say that the whole section from line 246 to 285 wasn't executed correctly.

https://github.com/tsolucio/corebos/blob/master/build/migrate6/migrate_from_vt60.php#L246

this is almost the same part as the previous error so it looks like this file wasn't executed corretly: there may be other changes missing. Try to very some of the other queries in this section.


RE: Migrate from vtiger 6.3 - pmax - 02-26-2016

Good! I think it went well now. This is the result of the upgrade: https://dl.dropboxusercontent.com/u/1374588/vtlib%20TSolucio%20coreBOS%20Customizations%20%20migrate%20from%20vtiger%20CRM%206.x%203rd.htm

The queries that failed were for tables already existing or changes already applied.

I proceed to apply all the updates from the CoreBos updater module: all but three were applied but just one giving error. The ones that failed:

cbupd-0000003 - DocumentRelatedList - ERROR: Class called without update record in application!!
cbupd-0000005 - EmailReports - already applied
cbupd-0000051 - inventoryproductstockcontrol - Changeset inventoryproductstockcontrol already applied!

After that, almost everything is working except:

1. If I try to see the details of an Account or Contact I get:

( ! ) Warning: call_user_func() expects parameter 1 to be a valid callback, class 'Documents' does not have a method 'isLinkPermitted' in C:\wamp\www\core\vtlib\Vtiger\Link.php on line 231
Call Stack
# Time Memory Function Location
1 0.0000 270384 {main}( ) ..\index.php:0
2 0.2808 16508904 include( 'C:\wamp\www\core\modules\Accounts\DetailView.php' ) ..\index.php:679
3 0.4836 16956904 Vtiger_Link::getAllByType( ) ..\DetailView.php:147
4 0.4836 16969056 call_user_func:{C:\wamp\www\core\vtlib\Vtiger\Link.php:231} ( ) ..\Link.php:231

2. When trying to access the details of a user:

( ! ) Fatal error: Uncaught exception 'Exception' with message 'unsupported dbtype "mysqli"' in C:\wamp\www\core\include\database\PearDatabase.php on line 781

( ! ) Exception: unsupported dbtype "mysqli" in C:\wamp\www\core\include\database\PearDatabase.php on line 781
Call Stack
#    Time    Memory    Function    Location
1    0.0000    270352    {main}( )    ..\index.php:0
2    0.1872    15397808    CRMEntity->track_view( )    ..\index.php:545
3    0.1872    15399160    Tracker->track_view( )    ..\CRMEntity.php:1050
4    0.1872    15403752    PearDatabase->sql_concat( )    ..\Tracker.php:91

3. I tried to create a Workflow, but it freezes trying to load Conditions, without giving any error.

4. Finally, what do you think it would be my best strategy to bring back my custom modules. The database already has all the information but the code isn't there. I tried copying them from my vtiger modules folder but I get this when I try to access the module:

Action name is missing. Please check the action name.


Sorry for such a long post, thank you again for your help!

PM


RE: Migrate from vtiger 6.3 - joebordes - 02-27-2016

cbupd-0000003 - DocumentRelatedList - ERROR: Class called without update record in application!!

this one is wrong and important. I don't know why. look for the database record in the table vtiger_cbupdater and make sure the file name and class name are correct

cbupd-0000005 - EmailReports - already applied
cbupd-0000051 - inventoryproductstockcontrol - Changeset inventoryproductstockcontrol already applied!

you should be able to safely ignore these two because you already have them from VT6. I think they will work.


RE: Migrate from vtiger 6.3 - joebordes - 02-27-2016

1.- execute this SQL directly against your database:

UPDATE vtiger_links SET handler = null, handler_class = null, handler_path = null WHERE handler = 'isLinkPermitted'

and let me know how it goes so I can add it to the migration script


RE: Migrate from vtiger 6.3 - joebordes - 02-27-2016

2. Have you changed the $dbconfig['db_type'] = 'mysql'; variable in config.inc.php ??


RE: Migrate from vtiger 6.3 - joebordes - 02-27-2016

3.- Workflows

That is going to be a hard one. You are getting a javscript error, not directly but in one of the webservice calls that is being made. I need to see that error. This is easy to see in the console both in firefox (specially with firebug) and chrome.


RE: Migrate from vtiger 6.3 - joebordes - 02-27-2016

4.- You have to program them again, there is no way around it, the structure is totally different. You will be able to keep the database structure and all the data but you will have to create the code.

That is basically:

- copy all files from the vtlib/ModuleDir directory into the directory of the module.
- change the three ModuleFile.* to YourModule.*
- edit and adapt the first part of YourModule.php
- adapt the language files

Start a new thread for this one and the workflow, those are probably going to take us a while.

Thank you for your patience and help to make this process better. BTW, you haven't said anything about the new changes from 6.3 and 6.4, there are probably changes there that need to be undone. Don't forget those, they could come back to bite you in the future.


RE: Migrate from vtiger 6.3 - pmax - 02-27-2016

(02-27-2016, 05:18 PM)joebordes Wrote: 1.- execute this SQL directly against your database:

UPDATE vtiger_links SET handler = null, handler_class = null, handler_path = null WHERE handler = 'isLinkPermitted'

and let me know how it goes so I can add it to the migration script

6 rows updated, that error is gone.

(02-27-2016, 05:19 PM)joebordes Wrote: 2. Have you changed the $dbconfig['db_type'] = 'mysql'; variable in config.inc.php ??

No, I wasn't aware of that, my config.inc.php from vtiger says 'mysqli' not 'mysql. I changed it and now that error is also gone. Great!

(02-27-2016, 04:52 PM)joebordes Wrote: cbupd-0000003 - DocumentRelatedList - ERROR: Class called without update record in application!!

this one is wrong and important. I don't know why. look for the database record in the table vtiger_cbupdater and make sure the file name and class name are correct

cbupd-0000005 - EmailReports - already applied
cbupd-0000051 - inventoryproductstockcontrol - Changeset inventoryproductstockcontrol already applied!

you should be able to safely ignore these two because you already have them from VT6. I think they will work.

fixed!

For some reason I had two entries in vtiger_relatedlist_seq so the function that returns the new unique id was returning a wrong id. I fixed the table and the change applied correctly.

joebordes3.- Workflows

That is going to be a hard one. You are getting a javscript error, not directly but in one of the webservice calls that is being made. I need to see that error. This is easy to see in the console both in firefox (specially with firebug) and chrome.


Fixed! Looking at the errror from firefox console, I noticed I had forgotten to disable "SQL Reports". Now they work!

Thanks again, I will move on to custom modules, I will open a new thread for that.

PM


RE: Migrate from vtiger 6.3 - joebordes - 02-27-2016

Wonderful!!

I dedicated some time to the other migration scripts and just uploaded the necessary steps. Truth is that the changes are VERY small (you can tell vtiger isn't doing much for their open source, as usual). In your case just execute this against your database:


Code:
DELETE FROM vtiger_wsapp_handlerdetails WHERE type = 'Google_vtigerHandler' or type = 'Google_vtigerSyncHandler';
DELETE FROM vtiger_wsapp_sync_state WHERE name IN ('Vtiger_GoogleContacts', 'Vtiger_GoogleCalendar');
DELETE FROM vtiger_wsapp WHERE name = 'Google_vtigerSyncHandler';
DROP TABLE vtiger_google_oauth2;
DROP TABLE vtiger_google_sync_settings;
DROP TABLE vtiger_google_sync_fieldmapping;
delete from vtiger_profile2utility where tabid in (19,40);

It is all Google related so I don't think it will affect if you don't execute it, because we don't use those tables for that.