You are not logged in.
Bonjour,
suite au post sur la mise à jour de 9.1 à 9.2 j'ai un problème maintenant avec les tickets.
Sur mon profil tout va bien, mais sur le profil de mes collègue rien n'apparait. Quand je passe en mode débug il me sort cette requête
SELECT 'glpi' AS currentuser, `glpi_tickets`.`id` AS `ITEM_0`, `glpi_tickets`.`name` AS `ITEM_1`, `glpi_tickets`.`id` AS `ITEM_1_id`, `glpi_tickets`.`id` AS `ITEM_1_id`, `glpi_tickets`.`content` AS `ITEM_1_content`, `glpi_tickets`.`status` AS `ITEM_1_status`, `glpi_entities`.`completename` AS `ITEM_2`, `glpi_tickets`.`content` AS `ITEM_3`, `glpi_tickets`.`status` AS `ITEM_4`, `glpi_tickets`.`type` AS `ITEM_5`, `glpi_tickets`.`date` AS `ITEM_6`, GROUP_CONCAT(DISTINCT `glpi_users_a5e2026cbcb683e774f93a59e24a62a4`.`id` SEPARATOR '$$##$$') AS `ITEM_7`, GROUP_CONCAT(DISTINCT CONCAT(`glpi_tickets_users_d1524bb2ea1d461ab90aed3b5f0e7e60`.`users_id`, ' ', `glpi_tickets_users_d1524bb2ea1d461ab90aed3b5f0e7e60`.`alternative_email`) SEPARATOR '$$##$$') AS `ITEM_7_2`, `glpi_tickets`.`priority` AS `ITEM_8`, GROUP_CONCAT(DISTINCT `glpi_users_f201be21cd638ee780d08cba4ceff0d4`.`id` SEPARATOR '$$##$$') AS `ITEM_9`, GROUP_CONCAT(DISTINCT CONCAT(`glpi_tickets_users_819efb92c8b927b345e489211ec8e43b`.`users_id`, ' ', `glpi_tickets_users_819efb92c8b927b345e489211ec8e43b`.`alternative_email`) SEPARATOR '$$##$$') AS `ITEM_9_2`, GROUP_CONCAT(DISTINCT CONCAT(IFNULL(`glpi_groups_1358be41ea7158319a888236ffba5355`.`completename`, '__NULL__'), '$#$',`glpi_groups_1358be41ea7158319a888236ffba5355`.`id`) SEPARATOR '$$##$$') AS `ITEM_10`, `glpi_tickets`.`time_to_resolve` AS `ITEM_11`, `glpi_tickets`.`status` AS `ITEM_11_status`, `glpi_itilcategories`.`completename` AS `ITEM_12`, `glpi_ticketsatisfactions`.`date_begin` AS `ITEM_13`, `glpi_tickets`.`date_mod` AS `ITEM_14`, `glpi_tickets`.`id` AS id
FROM `glpi_tickets`
LEFT JOIN `glpi_entities` ON (`glpi_tickets`.`entities_id` = `glpi_entities`.`id` )
LEFT JOIN `glpi_tickets_users` AS `glpi_tickets_users_d1524bb2ea1d461ab90aed3b5f0e7e60` ON (`glpi_tickets`.`id` = `glpi_tickets_users_d1524bb2ea1d461ab90aed3b5f0e7e60`.`tickets_id` AND `glpi_tickets_users_d1524bb2ea1d461ab90aed3b5f0e7e60`.`type` = 1 )
LEFT JOIN `glpi_users` AS `glpi_users_a5e2026cbcb683e774f93a59e24a62a4` ON (`glpi_tickets_users_d1524bb2ea1d461ab90aed3b5f0e7e60`.`users_id` = `glpi_users_a5e2026cbcb683e774f93a59e24a62a4`.`id` )
LEFT JOIN `glpi_tickets_users` AS `glpi_tickets_users_819efb92c8b927b345e489211ec8e43b` ON (`glpi_tickets`.`id` = `glpi_tickets_users_819efb92c8b927b345e489211ec8e43b`.`tickets_id` AND `glpi_tickets_users_819efb92c8b927b345e489211ec8e43b`.`type` = 2 )
LEFT JOIN `glpi_users` AS `glpi_users_f201be21cd638ee780d08cba4ceff0d4` ON (`glpi_tickets_users_819efb92c8b927b345e489211ec8e43b`.`users_id` = `glpi_users_f201be21cd638ee780d08cba4ceff0d4`.`id` )
LEFT JOIN `glpi_groups_tickets` AS `glpi_groups_tickets_819efb92c8b927b345e489211ec8e43b` ON (`glpi_tickets`.`id` = `glpi_groups_tickets_819efb92c8b927b345e489211ec8e43b`.`tickets_id` AND `glpi_groups_tickets_819efb92c8b927b345e489211ec8e43b`.`type` = 2 )
LEFT JOIN `glpi_groups` AS `glpi_groups_1358be41ea7158319a888236ffba5355` ON (`glpi_groups_tickets_819efb92c8b927b345e489211ec8e43b`.`groups_id` = `glpi_groups_1358be41ea7158319a888236ffba5355`.`id` )
LEFT JOIN `glpi_itilcategories` ON (`glpi_tickets`.`itilcategories_id` = `glpi_itilcategories`.`id` )
LEFT JOIN `glpi_ticketsatisfactions` ON (`glpi_tickets`.`id` = `glpi_ticketsatisfactions`.`tickets_id` )
WHERE `glpi_tickets`.`is_deleted` = '0' AND ( `glpi_tickets`.`status` IN ('1','2','3','4') ) GROUP BY `glpi_tickets`.`id` 5
ORDER BY ITEM_14 DESC
avec l'erreur
Unknown column 'glpi_tickets.time_to_resolve' in 'field list'
Effectivement la colonne n'existe pas.
Quand je regarde le fichier install/update_91_92.php je vois que les migrations ne se sont pas faites, comment les forcer ?
c'est étrange
Merci de votre aide
Last edited by Climberdav (2017-11-07 13:39:41)
GLPI 9.1.1 sur CentOS Linux release 7.4.1708 (Core) + FusionINventory
httpd-2.4.6-67.el7.centos.x86_64 / php-5.6.32-1.el7.remi.x86_64
PHP 5.6.32 (cli) (built: Oct 25 2017 06:49:52)/ Zend Engine v2.6.0, with Zend OPcache v7.0.6-dev
mariadb-5.5.56-2.el7.x86_64
Offline
Pour être plus précis, j'ai l'impression que le code à planté vers la ligne 147 du fichier install/update_91_92.php :
$migration->addField("glpi_knowbaseitemtranslations", "users_id", "integer");
$migration->migrationOneTable("glpi_knowbaseitemtranslations");
$migration->addKey("glpi_knowbaseitemtranslations", "users_id");
car je n'ai pas de clé user_id
GLPI 9.1.1 sur CentOS Linux release 7.4.1708 (Core) + FusionINventory
httpd-2.4.6-67.el7.centos.x86_64 / php-5.6.32-1.el7.remi.x86_64
PHP 5.6.32 (cli) (built: Oct 25 2017 06:49:52)/ Zend Engine v2.6.0, with Zend OPcache v7.0.6-dev
mariadb-5.5.56-2.el7.x86_64
Offline
Bon je me suis débrouillé avec un mysqldiff et quelques modif sur une install vierge en 9.2.
J'ai retrouvé une base clean
GLPI 9.1.1 sur CentOS Linux release 7.4.1708 (Core) + FusionINventory
httpd-2.4.6-67.el7.centos.x86_64 / php-5.6.32-1.el7.remi.x86_64
PHP 5.6.32 (cli) (built: Oct 25 2017 06:49:52)/ Zend Engine v2.6.0, with Zend OPcache v7.0.6-dev
mariadb-5.5.56-2.el7.x86_64
Offline