You are not logged in.
Pages: 1
Bonjour , voulant modifié le helpdesk , j'ai deja voulu connaître les variables autour.
Avec cette commande echo "<pre>".print_r($_POST,true)."</pre>";
j'ai pu affiché les variables post , mais j'ai une la vision de quelque chose de tres bizarre .
je me met sur un client et le $_POST["FK_entities"] est un 0 , je me met sur un autre client ,dans la meme entité , il est a 3
je me remet sur l'ancien et il est aussi a 3, je met mette sur une autre entité , et il reste a 3 , je fais pareil et la il change . bref
Pratiquement aucune $_POST["FK_entities"] n'est fiable .
Test effectué sur windows server 2003 R2 , sur glpi 0.72 et 0.72.1
Voila , merci de me repondre
Cordialement
Test GLPI 0.72 , 200 entités , 400 utilisateur .
Offline
> Pratiquement aucune $_POST["FK_entities"] n'est fiable .
C'est l'entité dans laquelle sera créée le ticket (pas forcément celle de l'utilisateur connecté)
+
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
oui mais quand tu selectionne un demandeur , il faut bien que le FK_entities soit le bon pour crée dans la bonne entité , sinon ca serait quelle variable qui indique l'entities quand tu selectionne un demandeur ?
Last edited by cedric.rohou (2009-09-15 14:56:49)
Test GLPI 0.72 , 200 entités , 400 utilisateur .
Offline
up
Test GLPI 0.72 , 200 entités , 400 utilisateur .
Offline
le fait que FK_entities change dépend des profils que possède le demandeur.
Si le demandeur n'a un accès qu'à l'entité 3 le ticket sera créé sur cette entité.
Si il a accès à plusieurs entités vous aurez le choix de l'entité.
MoYo - Julien Dombre - Association INDEPNET
Contribute to GLPI : Support Contribute References Freshmeat
Offline
le demandeur est rataché a une seule entité , et pourtant , il s'actualise qu'apres la deuxieme selection du demandeur
Test GLPI 0.72 , 200 entités , 400 utilisateur .
Offline
le demandeur est rataché a une seule entité , et pourtant , il s'actualise qu'apres la deuxieme selection du demandeur
pas compris
voilà comment ça se passe :
1- form pour nouveau ticket : positionné sur l'utilisateur qui est loggué (donc avec dropdown pour ses X entités s'il en a plusieurs en tant que technicien)
2- choix du user -> rechargement de la page
3- combo de sélection des entités si le demandeur appartient à plus d'une entité (-> rechargement du form). S'il n'a accès qu'à une entité, pas de rechargement
4 - on est sur le bon user et sa bonne entité, on déclare le ticket
Offline
Chez moi j'ai
1 -form pour nouveau ticket : positionné sur l'utilisateur qui est loggué (donc avec dropdown pour ses X entités s'il en a plusieurs en tant que technicien) bon
2- choix du user -> rechargement de la page bon
3 -S'il n'a accès qu'à une entité, pas de rechargement bon
4 - on est sur le bon user et sa bonne entité, on déclare le ticket pas bon
Le FK-Entities n'est pas le bon , il est sur la mauvaise entities ,mais quand on crée le ticket ca se met sur la bonne .
Test GLPI 0.72 , 200 entités , 400 utilisateur .
Offline
> quand on crée le ticket ca se met sur la bonne
Donc ? où est le bug ?
+
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
Je selectionne le demandeur ( il a 1 seule entité ) , et quand je la selectionne , je vois que le FK_entities n'est pas le bon
Test GLPI 0.72 , 200 entités , 400 utilisateur .
Offline
Pages: 1