You are not logged in.
Il existe des possibilités de notification pour chaque modification des tickets. cela peut dans certains cas génerer un grand nombre de notifications et ça noie un peut les notifications les plus importantes.
Pour les techniciens qui consultent fréquemment GLPI, un flag Lu /Non Lu sur les tickets pourrait permettre d'identifier les tickets modifiés depuis la derniere consultation par l'utilisateur. ça pourrait dans bien des cas remplacer des notifications.
Un peu sur le même principe que ce forum ou les sujets avec des nouveaux messages non lus sont marqués.
Trouver la panne avant de réparer...
GLPI10.0.16 (ubuntu 22.04 PHP8.1 Mariadb10.6 ) plugins : comportements 2.7.3 reports 1.16.0 formcreator 2.13.9, datainjection 2.13.5 fields 1.21.9
Offline
On pourrait effectivement se baser sur l'auteur de la date de la dernière modification pour différencier les tickets.
Mais par contre, si l'utilisateur connecté ouvre le ticket sans rien modifier, et que ce n'est pas lui l'auteur de la dernière modification, le ticket apparaitra toujours en Non lu (il n'y a aucun tracage des lecture de tickets dans GLPI)
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
il n'y a aucun tracage des lecture de tickets dans GLPI
pas encore ;-)
puisqu'on en est dans les propositions de fonctionnalités, on peut imaginer un bouton supplémentaire "lu".
ou même soyons fous : quand un utilisateur "lit" un ticket on enregitre users_id, tickets_id, date dans une table.
si la date de dernière modif du ticket est supérieure à la dernière date de lecture le ticket est "non lu"
le tout sans détruire les perfs de la base ni augmenter les temps d'affichage....
Trouver la panne avant de réparer...
GLPI10.0.16 (ubuntu 22.04 PHP8.1 Mariadb10.6 ) plugins : comportements 2.7.3 reports 1.16.0 formcreator 2.13.9, datainjection 2.13.5 fields 1.21.9
Offline