Welcome to GLPi feature request service.
Please check if the feature has not already been requested.
If not, please describe it

+30

Prevent solve of ticket / change / problem when 'to do' tasks are existing

Tomolimo 7 years ago updated by Yustas 2 years ago 9

Hello,

The idea is to prevent solving of items (Ticket, Change, Problem) when to do tasks are still existing.

Another way to say this is to permit solving of Tickets / Changes / Problems only when existing tasks are 'done' or 'information'.

We may show a message to inform Technicians that Ticket / Change / Problem cannot be solved as some tasks are still in 'to do' status.

Thank you,

Regards,

Tomolimo


+27
Started

Add patch panel in network assets

magaiverpr 6 years ago updated by Michał Panasiewicz 1 year ago 5

Today we have to do a "workaround" to control if I have a patchpanel in my network infraestructure. It will be cool if there an option to add path panel in the port manager of assets.

+25
Planned

PENDING STATUS: Time Limit

Rodrigo Morato Rodrigues 8 years ago updated by glpi 6 years ago 4

Regards.

Today, when we change the status of a ticket to PENDING, the ticket will remain in this state indefinitely, and the SLA timing is also stopped.
a) Is there any way to set a time limit for the ticket stay in PENDING status?

b) Is there any way to receive an alert notification email when the timeout achieve a metric, before the ticket out of the status PENDING (SLATICKET style)?

+25
Started

Event Management

Pablo Rodrigues 8 years ago updated by glpi 4 years ago 3
Implement a event management, like the ITIL v3 proposes.

Control of events, where various warnings come to a one incident.
https://en.wikipedia.org/wiki/Event_Management_(ITIL)
+23

IM/Chat Feature to Create/Update Tickets

M. Cecil Dietz 8 years ago updated 8 years ago 2
It would be great to have chat functionality within the ticketing system.
Users could initiate a chat session to make a new request or update an existing ticket using an IM/chat feature. When the chat session is finished an option could exist to create a ticket from the conversation or be added as a followup to an existing ticket.
+22

Closing the ticket via e-mail by the user

Kirill Lavrik 5 years ago 0

Hi, it would be cool to perform a closing of the ticket (the decision of the ticket) via electronic mail by the user.
By type as below:

Image 137


And it is also important to have a report (statistics) on such users and such closures.

+22

Automatic action run days

tyrone wyatt 7 years ago 0

Automatic actions run period only allows for start time and end time.

Unfortunately we have no option to set the run days in which the automatic actions run on.

As an example we would like the ability to set the closeticket automatic action to only run Monday-Friday.


+21

Assign license to a user

Megachip 5 years ago updated by gmbt 2 years ago 1

Any way to assign a (software) license to a user instead of the computer?

Most new license models (adobe, office etc) are user based, not (only) device based. 

These is a plugin:

https://github.com/FutureProcessing/glpi-fpsoftware

but seems not maintained anymore. 

I think that functionality should be provided by the core itself.

+21

Assign all tasks for a ticket and Change category

Jérôme STIVAL 7 years ago 0

Example : Create a new ticket (Demande) like : "Commande d'un nouveau PC"

it automatically generates a task list to do (workflow) :

- Passer la commande chez le fournisseur

- Livraison de la commande

- Installation de l'os du PC

- Installation des applications de base

- Livraison du PC à l'utilisateur

This would also make standard changes (ITIL standard)

It's look like a "Catalogue de services"


+20

New rule criteria for mail receivers

Erich Iseli 7 years ago updated by Carlos Castaño 9 months ago 26

For us it would be really helpful to be able to make sure the mails sent to our receivers e-mail address are only sent to that address (with optionally other recipients in the CC). This would ensure that if one in the CC answers to all (and thus also to the receiver's address), I can block the creation of a duplicate ticket.

Suggested criteria: number of TO-recipients

The rule would thus look like this:

Criteria

* To email header - is not - receiver@email.address

OR

* Number of To-recipients - greater than - 1

Action

* Reject email (with email response)