There are several limitations in GLPI 10 regarding cable & socket management:

1. You cannot define sockets with both front and rear contacts (this is required by patch panels)
2. Impact analysis does not consider cables (it considers connections only)
3. PDU plugs cannot be connected to assets (computers, network devices, etc)
4. Lines cannot be connect

So here is my proposal:

1. Sockets always have front & rear ports
2. Currently connections can only be established between
   • Network ports
   • USB devices and computers
     This needs to be expanded to allow
   • Network ports to socket (specifying if rear or front port is used)
   • Lines to network ports & sockets
   • Socket to socket (this is the case of connecting patch panels with rooms)
   • PDU plug to asset
   • PDU plug to PDU plug (to connect a power rail to a UPS plug)
3. Cables should be optional attributes of a connection (for those having numbered cables)
4. Impact analysis should show socket names, port numbers, and cable names (probably when clicking the connection line)

This can be done by other tools (such as netbox), but having it integrated in GLPI would be superb.

Also reported in forum https://forum.glpi-project.org/viewtopic.php?id=292630

Hello dear friends.
Many thanks to you for the development and improvement of the GLPI.

GLPI provides very convenient templates for solution and comments in tickets.

It is very convenient and simplifies and speeds up the work with tickets.
But it is very inconvenient that the template functions are not provided for sending a validation request.

It would be nice if you could add the ability to use templates for validation requests similar to follow-up or ticket solutions.
It would also be convenient if you could specify a specific approver for each validation request template.
We, as well as all GLPI users, would be very grateful if you could implement this template function in a validation request.

The thing is, when you share a link copying URL, you expect to share link with title:

I think can be created some interfaces to give data on each class, it has to look like this:

<meta property="og:title" content="Example Page">
<meta property="og:image" content="https://example.com/images/image.jpg">
<meta property="og:description" content="This is just an example page.">
<meta property="og:url" content="https://example.com/page.html">

And then link sharing will be looks like:

Add a different smtp server per entity in order to send email notification on différents domains.

For example: A common GLPI server for two companies with differents domains

Best regards

Importing assets directly from Intune (Microsoft Endpoint Manager) would be beneficial. A connector could grab this information via the MS Graph API. Intune has already lots of data about the asset like main user or serial number, hardware type and information like ram, disk etc. thx! 

When opening a ticket and selecting the Requester, the "plus" button refers to "Import A User" when it would be more practical to be "Add User", so you can add a new user without leaving the ticket. 

Have the ability to manage in profile configuration so that standard users (who have the simplified profile interface) can see changes, problems, and projects. (ITIL object) Without being able to modify.

When a power supply is assigned to an phone (only possible from components, not from phone) it will not shown components)

The current behavior:

When a major incident occurs, we receive a lot of call. The best practice is to create a ticket for the first caller and add each next callers as requester to this ticket.

Today GLPI allow to setup the sending of a notification to the “requester” based on the event “ticket creation”. Which means that the first user receive a notification.

GLPI allow also to setup a notification to the “requester” based on the event “New user in requesters” but this means that

• When adding user 2, the users 1 receives a second notification and the users 2 receives a first notification.
• When adding user 3, the users 1 receives a third notification, the users 2 receives a second notification and the users 3 receives a first notification.
• And so on…, when adding 20 users to a ticket, the user 1 receive 21 notifications…

As a consequence, we may not setup the notification to added users based on the event "new user in requesters"... Only the first user is notified.

The good news is that it is already possible today to send a notification automatically to each caller when the technician solve the incident.

My idea:

by adding a recipient “last requester added" to the recipient’s notification, we would be allow to send a notification to the added users only.

In this way, each users would be informed once when calling.

Merci à Jean-Mathieu, Julien et Bazile et tous les contributeurs pour GLPI :) and thank you for reading me.

Malamort

on GLPI 9.2