You are not logged in.
Bonjour,
Je travail sur GLPI 9.1.6 avec formcreator 2.5.2 mais j'ai fait quelques test avec la dernière version de GLPI et Formcreator, le problème est identique.
Je fait des import d'utilisateur depuis un AD, puis je fait une règle qui les ajoute à une entité suivant les groupe de l'AD auquel ils appartiennent. j'ai désactivé le groupe qui les ajoutes automatiquement au groupe root entity. chaque utilisateur est donc dans un groupe que j'ai créer, ajouté automatiquement au groupe via une règle en fonction des groupes de l'AD auxquels ils appartiennent.
Voici mon problème : lorsque ces utilisateur remplissent un formulaire, les notifications par mail ne fonctionne pas pour eux. l'administrateur reçois bien la notification, les observateurs présent dans le gabarit du ticket crée par le formulaire (peut importe le groupe dans lequel est l'observateur) aussi mais jamais l'utilisateur. à force de recherche j'ai compris que lorsque je met l'utilisateur dans le groupe root entity, les notifications par mail à l'utilisateur fonctionnent très bien. par contre des que je le met dans un des groupes crée, il ne reçois plus aucune notification.
les entité que j'ai crée sont enfant de root entity et le paramètre "Mode d'assistance" dans l'onglet Formulaire des entités est à "hérité de l'entité parente".
j'ai essayer de créer de nouvelle entités, essayé des paramètre différent, rien n'y fait, ça semble ne pas fonctionner des qu'un utilisateur est dans une entité autre que root entity.
auriez vous une solution pour résoudre ce problème svp?
Merci.
Offline
Bonjour
Le mode d'assistance n'influe pas sur l'envoi de notifications.
Quand les notifications ne sont apparemment pas crées, avez vous vérifié si elles existent dans la file d'attente ? Regardez aussi dans la corbeille. Les notifications dnasl acorbeille sont envoyées avec succès. Celles qui n'y sont pas sont en attente d'envoi ou bien un échec est survenu lors de l'envoi.
(Je suppose que vous avez une tâche cron en service pour exécuter l'ordonnanceur de tâches de GLPI)
No support with MP - Always run an upgrade task on a testing instance before running it on production! Always backup before any upgrade task!
Offline
Bonjour
Le mode d'assistance n'influe pas sur l'envoi de notifications.
Quand les notifications ne sont apparemment pas crées, avez vous vérifié si elles existent dans la file d'attente ? Regardez aussi dans la corbeille. Les notifications dnasl acorbeille sont envoyées avec succès. Celles qui n'y sont pas sont en attente d'envoi ou bien un échec est survenu lors de l'envoi.
(Je suppose que vous avez une tâche cron en service pour exécuter l'ordonnanceur de tâches de GLPI)
j'ai vérifié si elles ne sont pas dans la file d'attente (table glpi_queuedmails). j'y vois toutes les notifications envoyé lors de création de ticket classique (sans formulaire) aux utilisateurs et les notifications envoyé à l'administrateur (ticket classique + formulaire) mais il n'y a aucune notification envoyé aux utilisateurs lors de création d'un formulaire.
Offline
petit détail supplémentaire : dans la base de données, je change seulement la valeur de "entities_id" dans la table "glpi_profiles_users". quand je passe la valeur pour un utilisateur à 0 (valeur de l'id de root entity), il reçoit bien les mails et des que je change cette valeur en autre chose (l'id d'une autre entité), il ne reçoit plus rien. j'ai essayé aussi de mettre une entité qui n'existe pas, il reçois pas de mail non plus. des que la valeur est autre que l'id de root entity, il n'y a plus de notification.
Offline
j'ai (enfin) trouvé là solution! dans la creation/édition du formulaire, onglet "Destination", lorsqu'on édite le ticket de destination il y a l'option "Entité de destination" qui était sur "entité par défaut de l'utilisateur". je ne sais pas où on paramètre l'entité par défaut de l'utilisateur (dans l'onglet "habilisation" de l'utilisateur, on choisie la ou les entité mais j'ai pas vu d'option pour en mettre une par défaut). j'ai modifié l'option "Entité de destination" en "entité active". ainsi ça crée bien le ticket dans l'entité de l'utilisateur, ce qui doit probablement débloquer la notification. les ticket étaient avant sur l'entité "root entity", aucun utilisateur n'étant dans cette entité, ça devait bloquer les notification (et les débloquaient quand je forçais "entities_id" dans la table "glpi_profiles_users" à root entity pour l'utilisateur).
Offline