Bonjour,
Nous sommes passé à la version 2.7 hier soir.
Ce matin nous nous rendons compte que les nouveaux tickets ne sont pas visibles (voirs screenshot).
Pouvez vous m'aidez ?
Merci par avance.
[Corrigé 2.8] Les nouveaux tickets sont invisibles
Bonjour,
je pense avoir trouvé la source de l'erreur il s'agit dans la mesure ou le compteur affiche une valeur il doit s'agir de la mise à zero du champs de base de donnée qui ne se réalise pas quand, on fait un insert sans valeur.
Je n'arrive pas à reproduire le problème c'est pourquoi je vous demanderai de tester:
dans ./index_auth.php remplacer:
par
dans ./newticket_u.php ajouter:
après
ET
remplacer:
par
par la suite re-créer un nouveau ticket depuis un profile utilisateur avec pouvoir ou superviseur et voyez le resultat.
Cdt
je pense avoir trouvé la source de l'erreur il s'agit dans la mesure ou le compteur affiche une valeur il doit s'agir de la mise à zero du champs de base de donnée qui ne se réalise pas quand, on fait un insert sans valeur.
Je n'arrive pas à reproduire le problème c'est pourquoi je vous demanderai de tester:
dans ./index_auth.php remplacer:
Code : Tout sélectionner
$cnt5 = mysql_query("SELECT count(*) FROM `tincidents` WHERE technician='' and disable='0'");
Code : Tout sélectionner
$cnt5 = mysql_query("SELECT count(*) FROM `tincidents` WHERE technician='0' and disable='0'");
Code : Tout sélectionner
if($_POST['technician']=='') $_POST['technician'] = 0;
Code : Tout sélectionner
if ($_POST['technician']!="") $state=1; else $state=5;
remplacer:
Code : Tout sélectionner
echo "<option selected value=\"\">Aucun</option>";
Code : Tout sélectionner
echo "<option selected value=\"0\">Aucun</option>";
Cdt
GestSup: 3.2.47 | Debian: 12 | Apache: 2.4.59 | MariaDB: 11.5.2 | PHP: 8.3.12 | https://doc.gestsup.fr/
Bonjour,
j'ai modifié les points indiqués; l'erreur est toujours là; les tickets ne sont pas visibles aussi bien en [Vos Demandes/Non Attribuées] comme en [Toutes Les Demandes/Non Lues ou /Nouvelles Demandes]
ces nouveaux tickets sont par contre lisible directement dans la base de données.
Existe t il un moyen de downgrader pour revenir à la 2.6 ?
Merci d'avance
j'ai modifié les points indiqués; l'erreur est toujours là; les tickets ne sont pas visibles aussi bien en [Vos Demandes/Non Attribuées] comme en [Toutes Les Demandes/Non Lues ou /Nouvelles Demandes]
ces nouveaux tickets sont par contre lisible directement dans la base de données.
Existe t il un moyen de downgrader pour revenir à la 2.6 ?
Merci d'avance
GestSup 2.8 - Windows Serveur 2008 - Apache 2.2.22 - PHP 5.4.3 - MySQL 5.5.24 - VMware
J'ai pu récupérer la vue sur les tickets non lus en reinstallant la 2.6.
Le problème c'est que la base de donnée reste en 2.7, donc toutes nos resolutions sont remplacer par du code source.
De plus il n'est plus possible de modifier des parametres dans les tickets, je me retrouve systematiquement avec l'erreur "Erreur SQL ! Unknown column 'resolution' in 'field list'"
La creation de nouveaux tickets n'est plus possible non plus
Y a t il un script existant pouvant faire revenir la base de la 2.7 vers la 2.6 ?
Repasser le squeleton présent dans la 2.6 pourrait il resoudre le soucis sans effacer les tickets deja presents ni leur contenus ?
(j'ai toujours le dump de la base fait juste avant la mise à jour, peut etre serait il plus simple de reinjecter cette sauvegarde ?)
Le problème c'est que la base de donnée reste en 2.7, donc toutes nos resolutions sont remplacer par du code source.
De plus il n'est plus possible de modifier des parametres dans les tickets, je me retrouve systematiquement avec l'erreur "Erreur SQL ! Unknown column 'resolution' in 'field list'"
La creation de nouveaux tickets n'est plus possible non plus
Y a t il un script existant pouvant faire revenir la base de la 2.7 vers la 2.6 ?
Repasser le squeleton présent dans la 2.6 pourrait il resoudre le soucis sans effacer les tickets deja presents ni leur contenus ?
(j'ai toujours le dump de la base fait juste avant la mise à jour, peut etre serait il plus simple de reinjecter cette sauvegarde ?)
GestSup 2.8 - Windows Serveur 2008 - Apache 2.2.22 - PHP 5.4.3 - MySQL 5.5.24 - VMware
Bonjour,
je pense qu'il serait plus simple de debogguer votre problème sur la version 2.7 que de downgrader.
dans le fichier ./dashboard.php essayer de remplacer la ligne:
par
testé, si cela ne fonctionne vous avez un problème avec vos états sinon regarder la suite:
Il s'agit de comprendre pourquoi dans votre situation la requête SQL:
ne renvoi aucune ligne.
Pouvez-vous essayer de l'executer avec phpmyadmin pour voir si vous avez des résultats, tous se joue dans la partie :
Pour trouver les tickets qui ne sont pas affiché vous pouvez utiliser la requete suivante:
Si la valeur trouvé dans technician est null donc différente de zéro, vous pouvez passer cette requête:
Sinon essayer de recopier le fichier ./dashboard.php sur votre serveur depuis la derniere version de gestsup.
Sinon essayer de reproduire le bug sur la webdemo afin que je puisse débugger.
Enfin si cela ne fonctionne toujours pas envoyé moi un dump de votre base de données en MP afin que fasse des analyses.
Si vous souhaitez tous de même downgrader il faudra vous basé sur la sauvegarde réaliser pendant votre migration repertoire "/backup/ " et en ré-injectant votre base de données depuis "/_SQL/backup...", les changements entre la version 2.6 et la version 2.7 étant majeurs, le downgrade que vous décrivez ne fonctionnera pas.
Mais encore une fois je vous le déconseille il s'agit juste d'un problème de requete SQL...
tenez moi au courant.
Cdt
je pense qu'il serait plus simple de debogguer votre problème sur la version 2.7 que de downgrader.
dans le fichier ./dashboard.php essayer de remplacer la ligne:
Code : Tout sélectionner
INNER JOIN tstates ON tincidents.state=tstates.id
Code : Tout sélectionner
LEFT OUTER JOIN tstates ON tincidents.state=tstates.id
testé, si cela ne fonctionne vous avez un problème avec vos états sinon regarder la suite:
Il s'agit de comprendre pourquoi dans votre situation la requête SQL:
Code : Tout sélectionner
SELECT DISTINCT tincidents.* FROM tincidents INNER JOIN tstates ON tincidents.state=tstates.id WHERE tincidents.technician LIKE '0' AND tincidents.technician LIKE '%' AND tincidents.state LIKE '%' AND tincidents.techread LIKE '%' AND tincidents.disable='0' AND (tincidents.category LIKE '%') AND tincidents.subcat LIKE '%' AND tincidents.id LIKE '%' AND tincidents.user LIKE '%' AND tincidents.date_create LIKE '%' AND tincidents.state LIKE '%' AND tincidents.priority LIKE '%' AND tincidents.criticality LIKE '%' AND tincidents.title LIKE '%%%' ORDER BY tstates.number, tincidents.priority, tincidents.criticality ASC, date_create DESC LIMIT 0, 30
Pouvez-vous essayer de l'executer avec phpmyadmin pour voir si vous avez des résultats, tous se joue dans la partie :
Si vous ne trouver aucune ligne, regarder via phpmyadmin; la valeur dans la colonne "technician" sur dans la table "tincidents" sur les tickets n'étant pas affichés. Vérifier que la valeurs est bien égal à 0. Vous pouvez également vérifier que la colonne "disable" est bien à "0".WHERE tincidents.technician LIKE '0'
Pour trouver les tickets qui ne sont pas affiché vous pouvez utiliser la requete suivante:
Code : Tout sélectionner
SELECT * FROM `tincidents` WHERE technician='' and disable='0'
Code : Tout sélectionner
update tincidents set technician = '0' WHERE technician=''
Sinon essayer de reproduire le bug sur la webdemo afin que je puisse débugger.
Enfin si cela ne fonctionne toujours pas envoyé moi un dump de votre base de données en MP afin que fasse des analyses.
Si vous souhaitez tous de même downgrader il faudra vous basé sur la sauvegarde réaliser pendant votre migration repertoire "/backup/ " et en ré-injectant votre base de données depuis "/_SQL/backup...", les changements entre la version 2.6 et la version 2.7 étant majeurs, le downgrade que vous décrivez ne fonctionnera pas.
Mais encore une fois je vous le déconseille il s'agit juste d'un problème de requete SQL...
tenez moi au courant.
Cdt
GestSup: 3.2.47 | Debian: 12 | Apache: 2.4.59 | MariaDB: 11.5.2 | PHP: 8.3.12 | https://doc.gestsup.fr/
Bonjour,
la manip semble avoir regler le probleme.
Avant de valider la mise à jour de mon coté pour la renvoyer sur ma machine en production il semble qu'il reste un dernier souci:
sur ma machine de test en 2.7 lorsqu'un utilisateur creer un ticket alors il ne peut pas le voir dans la partie Attente PEC tant qu'aucuns techniciens n'aient recuperer son ticket.
Du coté technicien par contre pas de pb, le nouveau ticket est bien visible dans les Nouvelles Demandes coté technicien.
Une petite idée pour ce petit bug ?
Merci d'avance
la manip
Code : Tout sélectionner
LEFT OUTER JOIN tstates ON tincidents.state=tstates.id
Avant de valider la mise à jour de mon coté pour la renvoyer sur ma machine en production il semble qu'il reste un dernier souci:
sur ma machine de test en 2.7 lorsqu'un utilisateur creer un ticket alors il ne peut pas le voir dans la partie Attente PEC tant qu'aucuns techniciens n'aient recuperer son ticket.
Du coté technicien par contre pas de pb, le nouveau ticket est bien visible dans les Nouvelles Demandes coté technicien.
Une petite idée pour ce petit bug ?
Merci d'avance
GestSup 2.8 - Windows Serveur 2008 - Apache 2.2.22 - PHP 5.4.3 - MySQL 5.5.24 - VMware
Bonjour,
content de savoir que cela vous débloque, cependant cela signifie que vous avez une incohérence dans la liste de vos état. En effet l'état ayant l'id 5 "Non attribué" ne doit pas être present.
Regarder en PJ la capture, la liste des états et faite la vérification au besoin faites les modifications avec phpmyadmin.
Pour le second bug, l'utilisateur ne voit pas les tickets dans l'état "en attente de PEC" car il ne sont pas "en attente de PEC" .
Le ticket est dans l'état "Non attribué", si votre utilisateur ne voit pas cet état vous pouvez lui ajouter dans "administration" > "Droit" > "Utilisateur" et donner l'accès à:
Pour remedier à cela (v2.8) ou plus rapidement aller dans le fichiet ./dashboard.php et remplacer:
par
Ou bien j'ai mit en PJ le fichier ./dashboard.php avec ces corrections.
Cdt
content de savoir que cela vous débloque, cependant cela signifie que vous avez une incohérence dans la liste de vos état. En effet l'état ayant l'id 5 "Non attribué" ne doit pas être present.
Regarder en PJ la capture, la liste des états et faite la vérification au besoin faites les modifications avec phpmyadmin.
Pour le second bug, l'utilisateur ne voit pas les tickets dans l'état "en attente de PEC" car il ne sont pas "en attente de PEC" .
Le ticket est dans l'état "Non attribué", si votre utilisateur ne voit pas cet état vous pouvez lui ajouter dans "administration" > "Droit" > "Utilisateur" et donner l'accès à:
Mais tous cela serait trop simple sans un nouveau bug malgrès que le chriffre a coté de l'état soit correcte aucune demande n'est listée.side_your_not_attribute (Affiche vos demande non attribué)
Pour remedier à cela (v2.8) ou plus rapidement aller dans le fichiet ./dashboard.php et remplacer:
Code : Tout sélectionner
tincidents.$profile='$_GET[techid]'
Code : Tout sélectionner
(tincidents.$profile='$_GET[techid]' OR tincidents.technician='$_GET[techid]')
Cdt
- Fichiers joints
-
- PJ.rar
- (19.72 Kio) Téléchargé 455 fois
GestSup: 3.2.47 | Debian: 12 | Apache: 2.4.59 | MariaDB: 11.5.2 | PHP: 8.3.12 | https://doc.gestsup.fr/
Alors effectivement j'ai quelques incoherences de mon coté.
- OK pour le bug des user qui ne peuvent pas voir les ticket "non attribués": parfait !
- J'ai remplacer mon dashboard.php par votre version corrigé; j'ai des erreurs php sur chacunes de mes pages, je laisse un screenshot en PJ pour vous montrer. - Pour ma table tstate effectivement j'ai des choses differentes de mon coté; il n'y a pas d'etat "non attribué" (pas normal).
Il manque aussi les états rejetés mais c'est normal, ca a été configurer comme tel des la mise en place de gestsup chez nous (nous n'avons pas le droit de refuser des tickets)
je laisse un screenshot; par contre je ne trouve pas comment rajouter la ligne manquante pour les etats non attribué... Pas simple tout ca, mais ca reste interessant de voir comment ce depanne l'outil gestsup. Bon courage
- OK pour le bug des user qui ne peuvent pas voir les ticket "non attribués": parfait !
- J'ai remplacer mon dashboard.php par votre version corrigé; j'ai des erreurs php sur chacunes de mes pages, je laisse un screenshot en PJ pour vous montrer. - Pour ma table tstate effectivement j'ai des choses differentes de mon coté; il n'y a pas d'etat "non attribué" (pas normal).
Il manque aussi les états rejetés mais c'est normal, ca a été configurer comme tel des la mise en place de gestsup chez nous (nous n'avons pas le droit de refuser des tickets)
je laisse un screenshot; par contre je ne trouve pas comment rajouter la ligne manquante pour les etats non attribué... Pas simple tout ca, mais ca reste interessant de voir comment ce depanne l'outil gestsup. Bon courage
GestSup 2.8 - Windows Serveur 2008 - Apache 2.2.22 - PHP 5.4.3 - MySQL 5.5.24 - VMware
Bonjour,
les messages d'erreur afficher corresponde à des variable définit dans la prochaines version 2.8 qui sont ici incohérente et inutile.
Afin de ne pas être pollué jusqu’à la prochaine MAJ supprimer ces blocs:
et
Pour votre problème d'état vous pouvez utiliser l'option insérer de phpmyadmin si vous ne connaissez pas le SQL, cf PJ. cdt
les messages d'erreur afficher corresponde à des variable définit dans la prochaines version 2.8 qui sont ici incohérente et inutile.
Afin de ne pas être pollué jusqu’à la prochaine MAJ supprimer ces blocs:
Code : Tout sélectionner
// Play notify sound for tech and admin
if ($rparameters['notify']==1 && ($_SESSION['profile_id']==4 || $_SESSION['profile_id']==0))
{
$query=mysql_query("SELECT id FROM `tincidents` WHERE technician='0' and techread='0' and disable='0' and notify='0'");
$row=mysql_fetch_array($query);
if ($row[0]!=0) {
echo'<audio hidden="false" autoplay="true" src="./sounds/notify.ogg" controls="controls"></audio>';
$query = "UPDATE tincidents SET notify='1' WHERE id='$row[0]'";
$exec = mysql_query($query) or die('Erreur SQL !<br /><br />'.mysql_error());
}
}
Code : Tout sélectionner
if ($rparameters['debug']==1)
{
echo "
SELECT DISTINCT tincidents.*
$from
ORDER BY
$_GET[order] $_GET[way],
date_create DESC LIMIT $_GET[cursor],
$rparameters[maxline]";
}
- Fichiers joints
-
- Capture.PNG (17.98 Kio) Vu 11167 fois
GestSup: 3.2.47 | Debian: 12 | Apache: 2.4.59 | MariaDB: 11.5.2 | PHP: 8.3.12 | https://doc.gestsup.fr/