[Corrigé 2.8] Les nouveaux tickets sont invisibles

Vous avez trouvé un bug dans l'application (dernière version stable ou bêta): Décrivez le ici afin que la correction soit intégrée a la prochaine version.
ysbio
Gsup LEVEL 1
Messages : 22
Enregistré le : lun. 21 janv. 2013 08:58

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.
Fichiers joints
bug.jpg
bug.jpg (78.17 Kio) Vu 10477 fois
GestSup 2.8 - Windows Serveur 2008 - Apache 2.2.22 - PHP 5.4.3 - MySQL 5.5.24 - VMware
Avatar du membre
Flox
Administrateur du site
Messages : 9049
Enregistré le : jeu. 21 juin 2012 19:00

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:

Code : Tout sélectionner

$cnt5 = mysql_query("SELECT count(*) FROM `tincidents` WHERE technician='' and disable='0'"); 
par

Code : Tout sélectionner

$cnt5 = mysql_query("SELECT count(*) FROM `tincidents` WHERE technician='0' and disable='0'"); 
dans ./newticket_u.php ajouter:

Code : Tout sélectionner

if($_POST['technician']=='') $_POST['technician'] = 0;
après

Code : Tout sélectionner

if ($_POST['technician']!="") $state=1; else $state=5;
ET

remplacer:

Code : Tout sélectionner

echo "<option selected value=\"\">Aucun</option>";
par

Code : Tout sélectionner

echo "<option selected value=\"0\">Aucun</option>";
par la suite re-créer un nouveau ticket depuis un profile utilisateur avec pouvoir ou superviseur et voyez le resultat.

Cdt
GestSup: 3.2.47 | Debian: 12 | Apache: 2.4.58 | MariaDB: 11.3.2 | PHP: 8.3.6 | https://doc.gestsup.fr/
ysbio
Gsup LEVEL 1
Messages : 22
Enregistré le : lun. 21 janv. 2013 08:58

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
GestSup 2.8 - Windows Serveur 2008 - Apache 2.2.22 - PHP 5.4.3 - MySQL 5.5.24 - VMware
ysbio
Gsup LEVEL 1
Messages : 22
Enregistré le : lun. 21 janv. 2013 08:58

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 ?)
GestSup 2.8 - Windows Serveur 2008 - Apache 2.2.22 - PHP 5.4.3 - MySQL 5.5.24 - VMware
Avatar du membre
Flox
Administrateur du site
Messages : 9049
Enregistré le : jeu. 21 juin 2012 19:00

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:

Code : Tout sélectionner

INNER JOIN tstates ON  tincidents.state=tstates.id 
par

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
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 :
WHERE tincidents.technician LIKE '0'
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".

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'
Si la valeur trouvé dans technician est null donc différente de zéro, vous pouvez passer cette requête:

Code : Tout sélectionner

update tincidents set technician = '0' WHERE technician=''
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
GestSup: 3.2.47 | Debian: 12 | Apache: 2.4.58 | MariaDB: 11.3.2 | PHP: 8.3.6 | https://doc.gestsup.fr/
ysbio
Gsup LEVEL 1
Messages : 22
Enregistré le : lun. 21 janv. 2013 08:58

Bonjour,

la manip

Code : Tout sélectionner

LEFT OUTER JOIN tstates ON tincidents.state=tstates.id
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 :)
GestSup 2.8 - Windows Serveur 2008 - Apache 2.2.22 - PHP 5.4.3 - MySQL 5.5.24 - VMware
Avatar du membre
Flox
Administrateur du site
Messages : 9049
Enregistré le : jeu. 21 juin 2012 19:00

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 à:
side_your_not_attribute (Affiche vos demande non attribué)
Mais tous cela serait trop simple sans un nouveau bug :x malgrès que le chriffre a coté de l'état soit correcte aucune demande n'est listée.
Pour remedier à cela (v2.8) ou plus rapidement aller dans le fichiet ./dashboard.php et remplacer:

Code : Tout sélectionner

tincidents.$profile='$_GET[techid]' 
par

Code : Tout sélectionner

(tincidents.$profile='$_GET[techid]' OR tincidents.technician='$_GET[techid]')
Ou bien j'ai mit en PJ le fichier ./dashboard.php avec ces corrections.


Cdt
Fichiers joints
PJ.rar
(19.72 Kio) Téléchargé 395 fois
GestSup: 3.2.47 | Debian: 12 | Apache: 2.4.58 | MariaDB: 11.3.2 | PHP: 8.3.6 | https://doc.gestsup.fr/
ysbio
Gsup LEVEL 1
Messages : 22
Enregistré le : lun. 21 janv. 2013 08:58

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.
shot2.png
shot2.png (90.79 Kio) Vu 10449 fois
- 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é...
shot.png
shot.png (24.91 Kio) Vu 10449 fois
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
Avatar du membre
Flox
Administrateur du site
Messages : 9049
Enregistré le : jeu. 21 juin 2012 19:00

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:

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());
		
	}
}
et

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]";
		}
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
Fichiers joints
Capture.PNG
Capture.PNG (17.98 Kio) Vu 10448 fois
GestSup: 3.2.47 | Debian: 12 | Apache: 2.4.58 | MariaDB: 11.3.2 | PHP: 8.3.6 | https://doc.gestsup.fr/
ysbio
Gsup LEVEL 1
Messages : 22
Enregistré le : lun. 21 janv. 2013 08:58

Bonjour,
j'ai supprimé les blocs indiqués sur mon dashboard, et ajouté la ligne dans le tstate de ma base.
voici le nouveau bug:
shot3.png
shot3.png (31.91 Kio) Vu 10446 fois
GestSup 2.8 - Windows Serveur 2008 - Apache 2.2.22 - PHP 5.4.3 - MySQL 5.5.24 - VMware
Répondre