The GLPI could allow adding multiple mail addresses into Supplier form.

Some suppliers can have multiple emails to contact different departments.

When creating a ticket and associating a supplier into it, a drop-down could be shown to select the corresponding mail addresses.

Actually GLPI supports only a mail address by supplier.

Add ability to select "View All" in personal settings (Default entity list).

We can choose "View All" with the entity selector but we can not define this choice as default.

Currently, if we buy 100 PCs from a supplier at once, we would receive one invoice (one set of information).

In GLPI, we add 100 computer assets, then we have to manually type out 100 "Financial Information" tabs all containing the same information.

It would be way more practical, logical, convenient and efficient to create an "invoice record" to hold all the relevant information once, and then be able to link it to all the relevant assets purchased on the given invoice.

In the table glpi_logs, when a ticket is created, the fields in the table are filled. When a ticket is updated at the fields "title" or "description", in the table was wrote the text of old value and new value in the respective fields.

It would be wonderful if this same idea can be used for tasks, because when we update a task in the ticket, in the table it's don't saved the old value , only the ID of the task.

It would be greatl if it was possible to display the ticket categories independently from the entity.

example :

I have a root entity with Software category and Office, ERP as subcategories

In a child entity, I would like to add another category (ex: VPN) under the category of the root entity Software

and the logical displaying would be independent from entity (just use entities membership to display correctly) as :

Software

  >> Office

  >> ERP

  >> VPN

the VPN category would only be displayed to members of the child entity (and possibly their children entities)

Hello all,

I suggest to enable the possiblity to place two devices (items) in the same rack unit.

Example:

PDU #1 is placed in rack unit #1, facing front

PDU #2 is placed in rack unit #1, facing rear

This makes sense for devices which are very short in depth.

Or another example:

PDU #1 is placed in rack unit #1, facing front, only left half of the unit

PDU #2 is placed in rack unit #1, facing front, only right part of the unit

This makes sense for devices which are very small in width, or placed on a tray.

Actually every time I try to add a device facing [rear/front] on the same rack unit already used by a device facing [front/rear] I receive a "Not enough space to place the item" error.

Tested with PDU items and Network items.

I am on a GLPI 9.5.3 fresh installation where everything else is working perfect, so I suppose it is a deliberate feature.

Thank you all in advance

Can you allow technicians to add follow-ups to tickets when solved without changing the status back to processing.

Requesters follow-ups reopen ticket as per current behavior.

Would it be possible to have SFP and/or SFP+ network types for switches and other network material:

[New copper connectors](https://en.wikipedia.org/wiki/Small_form-factor_pluggable_transceiver) that are replacing RJ45 connectors.

It is in screen Assets → Network devices → Select an existing asset, tab Network ports, button Add → dropdown Ethernet port type, image below:

Give user the ability to link KB articles to racks

There are some users that I don't want GLPI to receive emails.

I know there's the option to disable the follow up in each ticket. But I'd like to set it up on users by default.

For example:

The event monitoring system that opens tickets in GLPI by email doesn't need to receive updates about the ticket progress since it's not even a person.

This happens less often but there are some users that don't want and don't need to receive the emails from the Service Desk software.

Currently, I need to deactivate it every time in each ticket. However, when we receive more than 20 or 30 tickets of this kind (events monitoring system) it's inhuman to do it always.