La table vtiger_field a subit une modification pendant l'application du patch qui semble poser problème pour la migration. Cette modification empêche l'ajout des nouveaux champs officiels pour l'intégration Asterisk (asterisk_extension et use_asterisk), ce qui à son tour empêche les préférences utilisateur d'être sauvegardés. Pour régler le problème, il faut supprimer le champs personnalisée avant de lancer la migration:
mysql vtigercrm5db -e "DELETE FROM vtiger_field where fieldname like '%ast_extension%'"
Pour la version 1.6.x d'asterisk, les permissions pour l'accès au manager ont changés, il faut mettre:
read = system,call,log,verbose,agent,user,config,dtmf,reporting,cdr,dialplan write = system,call,agent,user,config,command,reporting,originate
(non supporté par FreePBX, il faut l'ajouter manuellement dans /etc/asterisk/manager_custom.conf
mkdir /usr/share/vtigercrm rsync -avP /home/e-smith/files/ibays/vtiger/html/ /usr/share/vtigercrm/
Puis modifier le fichier config.inc.php pour qu'il ne pointe plus vers l'ancienne base (changer le nom de la base, peu importe ce que vous mettez, l'important est que l'ancienne base ne soit plus référencée ici).
mysqldump --add-drop-table vtigerdb > /tmp/vtiger_old.sql
Puis vérifier (très important) que le dump ne contienne pas use database dans l'entête (si par exemple on utilise les dumps fait par SME dans /home/e-smith/db/mysql, cette ligne est présente, dans ce cas, il faut l'enlever).
yum --enablerepo=fws-testing install smeserver-vtigercrm signal-event webapps-update
mysql vtigercrmdb < /tmp/vtiger_old.sql
db configuration etprop mysqld InnoDB enabled signal-event webapps-update for T in $(mysql vtigercrmdb -e 'show tables'); do mysql vtigercrmdb -e "alter table $T engine=InnoDB"; done
Se connecter sur https://serveur/vtigercrm (qui devrait rediriger vers https://serveur/vtigercrm/install.php), puis suivre la procédure de migration.