You are not logged in.
Bonjour,
Depuis l'installation de la version GLPI 0.90.3 + Wamp 3.0, je n'arrive absolument pas à visualiser les Tickets (affectés, à clore) dans la Vue Personnelle :
quelque soit le Profil concerné (Admin, Technicien, Valideur...) il faut absolument cliquer sur Vue Globale ou Tous pour voir les tickets, alors même qu'il y en a pour l'utilisateur testé (créés, affectés).
Je ne comprends pas cette différence par rapport à la version 0.84.7 que nous utilisons depuis un moment, et j'ai beau repasser en revue la Configuration Générale + celle des Profils : rien à faire pour activer la visibilité des tickets sur la page Accueil/Vue Personnelle d'un utilisateur : seuls les éléments Planning, et Notes apparaissent...
Toute aide serait la bienvenue : merci d'avance.
Sébastien
Offline
Avez-vous des erreurs dans les logs de GLPI ? en mode Debug ?
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
En fait, seule la Vue Globale fonctionne : j'ai bien des erreurs PHP/MySQL avec la Vue Personnelle..
php-errors.log :
2016-06-15 13:56:03 [8@###]
*** PHP Notice(8): Trying to get property of non-object
Backtrace :
inc\dbmysql.class.php:240
inc\problem.class.php:672 DBmysql->numrows()
inc\central.class.php:236 Problem::showCentralList()
inc\central.class.php:83 Central::showMyView()
inc\commonglpi.class.php:469 Central::displayTabContentForItem()
ajax\common.tabs.php:91 CommonGLPI::displayStandardTab()
sql-errors.log :
2016-06-15 13:56:03 [8@###]
*** MySQL query error:
SQL: SELECT DISTINCT `glpi_problems`.`id`
FROM `glpi_problems`
LEFT JOIN `glpi_problems_users`
ON (`glpi_problems`.`id` = `glpi_problems_users`.`problems_id`)
LEFT JOIN `glpi_groups_problems`
ON (`glpi_problems`.`id` = `glpi_groups_problems`.`problems_id`)WHERE `glpi_problems`.`is_deleted` = 0
AND ( (`glpi_problems_users`.`users_id` = \'8\'
AND `glpi_problems_users`.`type` = \'2\'))
AND (`status` IN (\'3\',\'2\')) ORDER BY date_mod DESC LIMIT 0,25
Error: Expression #1 of ORDER BY clause is not in SELECT list, references column 'glpi.glpi_problems.date_mod' which is not in SELECT list; this is incompatible with DISTINCT
Backtrace :
inc\problem.class.php:671
inc\central.class.php:236 Problem::showCentralList()
inc\central.class.php:83 Central::showMyView()
inc\commonglpi.class.php:469 Central::displayTabContentForItem()
ajax\common.tabs.php:91 CommonGLPI::displayStandardTab()
Je précise notre config actuelle de GLPI : 1 Entité, 0 Groupes
Il semblerait en creusant dans "central.class.php" que les appels READMY & READASSIGN échouent, contrairement à READALL ;
"
static function showGlobalView() {
$showticket = Session::haveRight("ticket", Ticket::READALL);
$showproblem = Session::haveRight("problem", Problem::READALL);
"
"
static function showMyView() {
global $DB, $CFG_GLPI;
$showticket = Session::haveRightsOr("ticket",
array(Ticket::READMY, Ticket::READALL, Ticket::READASSIGN));
$showproblem = Session::haveRightsOr("problem", array(Problem::READALL, Problem::READMY));
"
Last edited by seblam01 (2016-06-15 14:37:23)
Offline
En mode DEBUG avec le user "glpi", j'ai toujours le message d'erreur (16x de suite) sur l'onglet "Vue Personnelle" :
PHP Notice: Trying to get property of non-object in C:\wamp\www\glpi\inc\dbmysql.class.php at line 240
J'y ai aussi remarqué une erreur systématique (sans doute liée), quand j'essaye d'accéder au menu "Traitement Ticket" sur n'importe quel ticket, quelque soit son statut :
Fatal error: Call to a member function fetch_assoc() on boolean in C:\wamp\www\glpi\inc\dbmysql.class.php on line 280
Call Stack
# Time Memory Function Location
1 0.0000 143704 {main}( ) ...\common.tabs.php:0
2 0.2031 7191632 CommonGLPI::displayStandardTab( ) ...\common.tabs.php:91
3 0.7969 15216176 CommonGLPI::displayStandardTab( ) ...\commonglpi.class.php:444
4 0.7969 15218136 Ticket::displayTabContentForItem( ) ...\commonglpi.class.php:469
5 0.8125 15248640 Ticket->showTimeline( ) ...\ticket.class.php:606
6 0.8125 15248704 Ticket->getTicketActors( ) ...\ticket.class.php:6244
7 0.8281 15251424 DBmysql->fetch_assoc( ) ...\ticket.class.php:6556
J'ai finalement également ces erreurs récurrentes qui apparaîssent dans : apache_errors.log
[Thu Jun 16 11:06:57.624939 2016] [authz_core:error] [pid 2340:tid 1608] [client XX.XX.X.XXX:52469] AH01630: client denied by server configuration: C:/Apache24, referer: xxxx://####.###.##/front/central.php
[Thu Jun 16 11:06:57.624939 2016] [authz_core:error] [pid 2340:tid 1636] [client XX.XX.X.XXX:52470] AH01630: client denied by server configuration: C:/Apache24, referer: xxxx://####.###.##/front/central.php
[Thu Jun 16 11:06:57.734312 2016] [core:error] [pid 2340:tid 1608] (20024)The given path is misformatted or contained invalid characters: [client XX.XX.X.XXX:52469] AH00127: Cannot map GET /ajax/common.tabs.php?_target=/front/central.php&_itemtype=Central&_glpi_tab=Central$3&id=0 HTTP/1.1 to file, referer: xxxx://####.###.##/front/central.php
[Thu Jun 16 11:06:57.796811 2016] [core:error] [pid 2340:tid 1636] (20024)The given path is misformatted or contained invalid characters: [client XX.XX.X.XXX:52470] AH00127: Cannot map GET /front/cron.php HTTP/1.1 to file, referer: xxxx://####.###.##/front/central.php
[Thu Jun 16 11:06:58.703043 2016] [core:error] [pid 2340:tid 1592] (20024)The given path is misformatted or contained invalid characters: [client XX.XX.X.XXX:52468] AH00127: Cannot map GET /ajax/updatecurrenttab.php?itemtype=Central&id=0&tab=1 HTTP/1.1 to file, referer: xxxx://####.###.##/front/central.php
[Thu Jun 16 11:06:58.718668 2016] [core:error] [pid 2340:tid 1608] (20024)The given path is misformatted or contained invalid characters: [client XX.XX.X.XXX:52469] AH00127: Cannot map GET /ajax/common.tabs.php?_target=/front/central.php&_itemtype=Central&_glpi_tab=Central$1&id=0 HTTP/1.1 to file, referer: xxxx://####.###.##/front/central.php
Offline
La version actuelle de GLPI n'est pas compatible avec la version 5.7 de MySQL ou MariaDB ; il faut impérativment rester en 5.5
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
Bonjour,
Si je tente un "logical downgrade" de MySQL 5.7. en 5.6, cela sera-t-il suffisant, ou faut-il vraiment repasser en 5.5 ?
Les pré-requis nécessaire à la version 0.90 ne sont pas très clairs en général, et encore moins sous Windows...
C'est quand même dommage, car à part quelques soucis de Vue des tickets qui ne remonte pas bien - la construction des Array PHP échoue, notamment à cause de l'option "distinct" du SELECT en BD SQL - tout le reste fonctionne plutôt bien..
Je précise mes versions actuelles : Windows 2k8R2 + Wamp 3.0 + GLPI 0.90.3 + FakeSendmail
pour la partie mailing PHP (je n'ai pas réussi à la faire fonctionner en SMTP) + Authentification Windows intégrée sur AD avec module NTLM mod_authn_ntlm (SSPI incompatible avec Apache 2.4).
Wamp 3.0 32bits : Apache 2.4.17 (Win32) + PHP 5.6.15 + MySQL 5.7.9
Offline
Cela ne fonctionnera pas avec les requetes utilisant les group by. Donc en gros tout le moteur de recherche est à ré écrire
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
Bonjour et merci pour les précisions.
Toujours est-il que j'ai suivi les précos de MySQL pour rétrograder uniquement la BD de 5.7.9 en 5.6.31, et le résultat est concluant : la Vue Personnelle utilisateur et la partie "Traitement du Ticket" fonctionnent bien ; ne reste plus que les warnings en logs Apache, plus d'erreurs PHP ni SQL...
Pour ceux que ça pourraient intéresser, voici la procédure de "Downgrade" suivie :
1) Sauvegarde de c:\wamp : au cas où
2) System Table Changes : requêtes préventives SQL passées sur la base entière
In MySQL 5.7.13, system table columns that store user@host string values were increased in length. Before downgrading to a previous release, ensure that there are no user@host values that exceed the previous 77 character length limit, and perform the following mysql system table alterations:
• mysql> ALTER TABLE mysql.proc MODIFY definer char(77) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL DEFAULT '';
• mysql> ALTER TABLE mysql.event MODIFY definer char(77) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL DEFAULT '';
• mysql> ALTER TABLE mysql.tables_priv MODIFY Grantor char(77) COLLATE utf8_bin NOT NULL DEFAULT '';
• mysql> ALTER TABLE mysql.procs_priv MODIFY Grantor char(77) COLLATE utf8_bin NOT NULL DEFAULT '';
The maximum length of MySQL user names was increased from 16 characters to 32 characters in MySQL 5.7.8. Before downgrading to a previous release, ensure that there are no user names greater than 16 characters in length, and perform the following mysql system table alterations:
• mysql> ALTER TABLE mysql.tables_priv MODIFY User char(16) NOT NULL default '';
• mysql> ALTER TABLE mysql.columns_priv MODIFY User char(16) NOT NULL default '';
• mysql> ALTER TABLE mysql.user MODIFY User char(16) NOT NULL default '';
• mysql> ALTER TABLE mysql.db MODIFY User char(16) NOT NULL default '';
• mysql> ALTER TABLE mysql.procs_priv MODIFY User char(16) binary DEFAULT '' NOT NULL;
The Password column of the mysql.user table was removed in MySQL 5.7.6. All credentials are stored in the authentication_string column, including those formerly stored in the Password column. To make the mysql.user table compatible with previous releases, perform the following alterations before downgrading:
• mysql> ALTER TABLE mysql.user ADD Password char(41) character set latin1 collate latin1_bin NOT NULL default '' AFTER user;
• mysql> UPDATE mysql.user SET password = authentication_string where LENGTH(authentication_string) = 41 and plugin = 'mysql_native_password';
• mysql> UPDATE mysql.user SET authentication_string = '' where LENGTH(authentication_string) = 41 and plugin = 'mysql_native_password';
The help_* and time_zone* system tables changed from MyISAM to InnoDB in MySQL 5.7.5. Before downgrading to a previous release, change each affected table back to MyISAM by running the following statements:
• mysql> ALTER TABLE mysql.help_category ENGINE='MyISAM' STATS_PERSISTENT=DEFAULT;
• mysql> ALTER TABLE mysql.help_keyword ENGINE='MyISAM' STATS_PERSISTENT=DEFAULT;
• mysql> ALTER TABLE mysql.help_relation ENGINE='MyISAM' STATS_PERSISTENT=DEFAULT;
• mysql> ALTER TABLE mysql.help_topic ENGINE='MyISAM' STATS_PERSISTENT=DEFAULT;
• mysql> ALTER TABLE mysql.time_zone ENGINE='MyISAM' STATS_PERSISTENT=DEFAULT;
• mysql> ALTER TABLE mysql.time_zone_leap_second ENGINE='MyISAM' STATS_PERSISTENT=DEFAULT;
• mysql> ALTER TABLE mysql.time_zone_name ENGINE='MyISAM' STATS_PERSISTENT=DEFAULT;
• mysql> ALTER TABLE mysql.time_zone_transition ENGINE='MyISAM' STATS_PERSISTENT=DEFAULT;
• mysql> ALTER TABLE mysql.time_zone_transition_type ENGINE='MyISAM' STATS_PERSISTENT=DEFAULT;
The plugin and servers system tables changed from MyISAM to InnoDB in MySQL 5.7.6. Before downgrading to a previous release, change each affected table back to MyISAM by running the following statements:
• mysql> ALTER TABLE mysql.plugin ENGINE='MyISAM' STATS_PERSISTENT=DEFAULT;
• mysql> ALTER TABLE mysql.servers ENGINE='MyISAM' STATS_PERSISTENT=DEFAULT;
The definition of the plugin column in the mysql.user table differs in MySQL 5.7. Before downgrading to a MySQL 5.6 server for versions 5.6.23 and higher, alter the plugin column definition using this statement:
• mysql> ALTER TABLE mysql.user MODIFY plugin CHAR(64) COLLATE utf8_bin DEFAULT 'mysql_native_password';
Before downgrading to a MySQL 5.6.22 server or older, alter the plugin column definition using this statement:
• mysql> ALTER TABLE mysql.user MODIFY plugin CHAR(64) COLLATE utf8_bin DEFAULT '';
As of MySQL 5.7.7, the sys schema is installed by default during data directory installation. Before downgrading to a previous version, it is recommended that you drop the sys schema:
• mysql> DROP DATABASE sys;
3) Commandes SQL passées en mode Admin : préparation de la rétroversion
C:\wamp\bin\mysql\mysql5.7.9\bin>mysqldump.exe --add-drop-table --events -u root -p --all-databases --force > all_5_7_databases_dump.sql
C:\wamp\bin\mysql\mysql5.7.9\bin>mysql -u root -p --execute="set global innodb_fast_shutdown=0"
C:\wamp\bin\mysql\mysql5.7.9\bin>mysqladmin -u root -p shutdown
C:\wamp\bin\mysql\mysql5.7.9\bin>cd..
C:\wamp\bin\mysql\mysql5.7.9>del data\ib_logfile*
C:\wamp\bin\mysql\mysql5.7.9>
4) Installation MySQL en v5.6.31 : installation classique du package .msi dans 1 nouveau répertoire
5) Commandes SQL passées en mode Admin : migration vers v5.6.31
C:\Program Files (x86)\MySQL\MySQL Server 5.6\bin>mysql -u root -p --execute="source all_5_7_databases_dump.sql" --force
Enter password: ************
C:\Program Files (x86)\MySQL\MySQL Server 5.6\bin>mysql_upgrade -u root -p
Enter password: ************
OK
C:\Program Files (x86)\MySQL\MySQL Server 5.6\bin>mysql -u root -p --execute="set global innodb_fast_shutdown=0"
Enter password: ************
C:\Program Files (x86)\MySQL\MySQL Server 5.6\bin>mysqladmin -u root -p shutdown
Enter password: ************
6) Dernière modifs : activation version 5.6.31
Déplacement du répertoire complet pour écraser C:\wamp\bin\mysql\mysql5.7.9 (sauvegarder my.ini et wampserver.conf au préalable pour les remettre ensuite) par : C:\wamp\bin\mysql\mysql5.6.31
- Service MySQL : au préalable il faut penser à MAJ le my.ini avec le nouveau chemin 5.6.31 (au lieu du 5.7.9).. et supprimer le service via la console wampserver.
- MAJ wampmanager.conf : avec le nouveau chemin 5.6.31, redémarrer le wampserver et recréer le service via sa console.
7) Utilisateurs MySQL : il a fallu recréer les Comptes/MDP à l’identique comme en 1ère install
- Root (n’avait plus de MDP par défaut)
- GLPI
- TCSBackupUser (que j'utilise en Select/Lock tables pour les dumps programmé par tâche planifiée)
Last edited by seblam01 (2016-07-01 14:50:10)
Offline
Il est prévu de modifier le moteur de recherche pour prise en compte de MySQL 5.7
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline