I request the blocking of the edition of the ticket texts made by the agents. Ticket text can be changed at any time without proper tracking. Ideally, changing the ticket description should be blocked or released only to the technician assigned to the ticket and that the changed text should be recorded in the ticket history.

Migrate the current GLPI application to a Progressive Web App, which allows you to run GLPI natively on different platforms (Web, iOS, Android, etc). And to take advantage of local storage, run offline, push notifications, performance, access to hardware, access to the homescreen of the device, among others.

http://blog.ionic.io/what-is-a-progressive-web-app/

https://codigofacilito.com/articulos/progressive-apps

https://developers.google.com/web/progressive-web-apps/

Actuellement, on ne peut paramétré qu'un destinataire (ou un groupe) qui recevra toutes les mails sur les alertes sur les fins de contrat.

L'idée est de pouvoir choisir quelle notification de mail envoyer pour chaque contrat ou chaque type de contrat. Ainsi, l'équipe réseau recevra les alertes pour les fins de contrat du réseau, l'équipe système recevra les mails qui le concernent.. ect. Tout le monde ne sera pas prévenu à chaque fois.

Hi.

We're migrating off Jira, because Jira lacks asset management features. One supergood feature of Jira, even killer feature, are mentions. When you are filling a text form, you can write @UserName (this will be automatically filled in as you type) and when you push save, the user "UserName" will receive an email/Jira notification (whatever preference the user has).

It would be very awesome to have such feature in GLPI - be it tickets, wiki, FAQ. This speeds up communication by very large margin (although it not might look like it at the first sight).

Add possibility to automaticaly open new ticket when a contract, certify, warranty or any objects with lifetime has expired or expiring 

Markdown support enables a better communications among the interested parties for:

• Code snippets
• Images (screenshots)

Also it is faster than the WYSIWYG solution field.

Markdown should be supported in:

• Ticket description
• Ticket solution
• Ticket followups

The option to create a problem from a ticket already exists.

The option to create a change from a problem already exists.

But no option to create a ticket from a problem.

Create a ticket from a problem would be very useful feature when logging repeat tickets of the same problem.

An example would be that the internet is down for all users, the hotliner or technician would need to follow complete the process to log new tickets:

Current process: Create a new ticket manually by entering the requester, category, title, description, submit and adding the ticket to the problem.

New process: Click click create a ticket from problem, enter requester and submit.

I have used the option in another service desk package in the past and this feature is a real time saver. This feature encourages all tickets to be logged by service desk operators and technicians.

A mock up of Create a ticket from a problem.