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

It would be beneficial to create custom user profiles in GLPI based on departments and assign permissions to different entities.

(This example is very simplified)

Example:

1. User Profiles:

   • IT Department
   • HR Department
   • Finance Department
   • Marketing Department

2. Permissions:

   • Tickets
   • Assets
   • Projects

3. Entities:

   • IT Entity
   • HR Entity
   • Finance Entity
   • Marketing Entity

Permission Matrix:

Collaborative Projects:

Explanation:

• IT Entity: IT and Finance departments collaborate on Project A.
• HR Entity: HR and Marketing departments collaborate on Project B.
• Finance Entity: IT, Finance, and Marketing departments collaborate on Project C.
• Marketing Entity: Marketing, HR, and IT departments collaborate on Project D.

Benefits:

• No need to switch profiles.
• All information is available in one view.
• Users see only the departments and entities where they have permissions.
• Simplifies workflow and improves efficiency.
• Enhances collaboration by allowing multiple departments to share permissions within the same entity.

With templates, you can set rules for defining items like tickets or assets. Applying this to profile customization in GLPI allows users to work within the full structure of the root entity but only see departments and entities where they have permissions. This avoids the need to change profiles to work in different departments.

English:

Title: Implementation of Proximity Search Criteria in GLPI

Description: Taking advantage of the geolocation capabilities in GLPI and its integration with the OpenStreetMap API, I suggest analyzing the feasibility of implementing a search criterion that allows identifying tickets within a radius or road distance of X km from a selected location or the current location determined by GPS. This feature would be extremely useful to optimize technicians' time, especially when they are traveling to remote areas to resolve incidents. By enabling the advancement of other tickets in the region, the efficiency and utilization of time would be significantly improved.

Benefits:

1. Time Optimization: Technicians can anticipate services while traveling.

2. Efficiency in Service: Reduction of idle time and increase in completed tickets.

3. Improvement in Ticket Management: Better resource allocation and ticket prioritization.

4. Customer Satisfaction: Reduction in waiting time for problem resolution.

Sugestão de Melhoria para o GLPI: Critério de Busca por Proximidade

Português:

Título: Implementação de Critério de Busca por Proximidade no GLPI

Descrição: Com a possibilidade de geolocalização das localizações no GLPI e a integração da API do OpenStreetMap, sugiro analisar a viabilidade de implementar um critério de busca que permita identificar chamados dentro de um raio ou distância rodoviária de X km de uma localidade selecionada ou da localização atual determinada por GPS. Essa funcionalidade seria extremamente útil para otimizar o tempo dos técnicos, principalmente quando estão se deslocando para áreas remotas para resolver incidentes. Ao possibilitar o adiantamento do atendimento de outros chamados na região, a eficiência e a utilização do tempo seriam significativamente melhoradas.

Benefícios:

1. **Otimização do Tempo**: Técnicos podem antecipar atendimentos enquanto estão em deslocamento.

2. **Eficiência no Atendimento**: Redução de tempo ocioso e aumento de atendimentos concluídos.

3. **Melhoria na Gestão de Chamados**: Melhora na alocação de recursos e priorização de chamados.

4. **Satisfação do Cliente**: Redução do tempo de espera para resolução dos problemas.

---

When using a ticket, I want to assign some consumables to it and have them be adjusted in the consumables panel.

So, if I have a printer that the team submitted a ticket for more ink, 

1. I go into the ticket
2. click a new "consumables" tab
3. Add the consumables to the ticket (just like items, only with the extra "consumables" data like who it's assigned to)
4. The inventory in consumables changes to reflect the ink that was used.

When creating a dashboard, could we possibly be able to integrate "saved search" results as widgets ?
Thanks in advance

Lorsque nous créons des "tableaux de bord" (ou 'dashboard'), peut-on imaginer une possibilité d'intégrer les résultats des "recherches sauvegardées" sous forme de widgets ?
Merci par avance

Please add variables to the ticket template. Such as the time and date in the title and description field

When an item is being assigned to a person, it shows up under "Used items" list in person view, but there's no entry about used items under person's historical view. On the other hand, if an asset's history is being viewed, history tab shows the history of users to whom the asset was/is assigned to.

This would enable to track what has been ever assigned to user during the user's whole GLPI lifecycle, also this would enable a lot easier tracking of assets - for example assets were assigned to someone else by mistake or by somekind of automation mistake. Currently one has to know the asset name/number first.

I suggest adding the option to add a floorplan to graphically show the location of the PCs. I share an example:

The display of pc's in the form of list is great. But I think that an ideal complement would be to provide the application with the ability to visualize the location of the devices on a floorplan.

# glpi

Glpi Deployment on Kubernetes with persistent volumes and SSL certificate

Glpi Prerequisites - WebServer, PHP, Mysql/Mariadb Database.

Glpi Key Directories - /var/www/html/glpi/{config, plugins, marketplace.Files}.

MariadDB - /var/lib/mysql

Prerequisites for deploying GLPI:-

Kubernetes Cluster

Shared Storage for PV (You may also use local storage, but it is not recommended.)

1. Clone above repo - https://github.com/Dineshk1205/glpi.git

$ git clone https://github.com/Dineshk1205/glpi.git

2. Crate MariaDB root password as secret –

$ kubectl create secret generic mariadb --from-literal=mariadb-root-password=xxxxx

3. Create a glpi namespace.

$ Kubectl create ns glpi

4. Extract controller-v1.9.0.tar.gz file

$ tar -xvf controller-v1.9.0.tar.gz

6. Installing the Nginx controller helm is required.

Helm installation –

$curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3

$ chmod 700 get_helm.sh

$ ./get_helm.sh

6. Nginx deployment: -

Switch to ingress-controller directory.

$ cd ingress-nginx-controller-v1.9.0/charts/ingress-controller

7. Create a ingress-controller namespace

$ kubectl create namespace ingress-nginx

8. Run the following command to install the nginx ingress –

$ helm install -n ingress-nginx ingress-nginx -f values.yaml.

9. SSL Certificate Configuration –

Generate a self-signed certificate or use ca certified certificate.

Crate Secret using Certificate key and cert file in glpi namespace

$ kubectl create secret tls glpi-tls --key xx.key --cert xx.crt -n glpi

10. Update the IP address Range in metallb-pool.yaml file based on your network

11. Update host name in ingress.yaml based on your requiremnts

12. Finally, Install MariaDB And glpi

Switch to cloned Directory glpi and run the below command

$ kubectl apply -f .

Check pod status

$ kubectl get pods -A

Once pods are up, check glpi IP to access the GLPI GUI.

$ kubectl get ingress -n glpi

Create DNS records for the above IP ( IP is above ingress IP, and Hostname will be matched with ingress.yaml file hostname).Access GLPU using FQDN.

DB for Configuring the GLPI

In the Kubernetes cluster, check MariaDB IP

$ kubectl get svc

Note down above mariadbsv cluster IP; use IP for connected Glpi.SQL user use root as user and enter a password. (Password created as secret in previous steps)

Hello, dear GLPI-comminity! I wonder, is it possible to make a dark-mode right on the menu up-right, or somewhere else on main screen to easily change it in the evening? Thanks!