Today, when you have a root entity and several child entities, whenever you add any item to the child entities, it ends up being shared with all of them. However, there should be an option to create an exception. Currently, you are forced to share with al

Hi!

I would like to propose the addition of a feature that allows users to log in and register to the GLPI system using Azure AD B2C. This integration could significantly streamline the onboarding process for new users.

Benefits:

• Faster User Integration: By enabling Azure AD B2C integration, organizations can quickly onboard new users without the need for manual account creation. This can greatly speed up the process and reduce administrative overhead.

• Domain-Based User Validation: The system could validate new users based on the domain configured in the client’s entity. This ensures that only users from allowed domains can register and log in, enhancing security and control.

• SSO Configuration: This feature would facilitate the configuration of Single Sign-On (SSO) without the need to register an enterprise application for each client tenant. This can simplify the setup and maintenance of SSO across multiple client environments.

Why This Solution is Beneficial:

Current solutions require adding login buttons for each registered enterprise application through which users authenticate into GLPI. This means that every new user must select the button corresponding to their organization, potentially revealing the list of organizations with which we collaborate.

Integrating Azure AD B2C addresses this issue. Users can log in seamlessly using a unified method, without needing to see or select between different organizational buttons. This enhances both security and user experience by keeping organizational details concealed and simplifying the login process.

Implementing this feature would provide a more modern and efficient user management experience within GLPI, aligning with current best practices in identity management.

Marcin

Hello.

It would be great if you made consistent approval in the business rules for tickets.

example:

an application was created / approver #1, then if approver #1 approved, then the ticket was transferred to approver #2, etc.

# 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)

it would be great if in project tasks and projects when you assign the status Closed and this is indicated as Finished State, that percentage of the respective task goes to 100%.

We would need a function with which one can select and add several assets at once in the ticket creation. The best thing would be to be able to select several assets in the asset view via mass editing and to create a ticket with the selected ones right away.

When a user is reaching the satisfaction survey screen, the rating field is defaulted to 3 stars. Many of our users leave this field to 3 stars instead of providing a real rating. I think it would make more sense to have no default on this field to force the user to provide a relevant rating on his own.

ca serait bien de faire un pont ou une liaison entre les tickets issus des tâches des projets pour que à chaque fois que le ticket soit cloturé que le pourcentage de la tâche correspondante passe à 100%

Hi all,

I think can be usefull add some fields when I see the item under task (glpi/front/ticket.form.php?id=xxx) on this view; could be usefull that user can customize this view with filed he needs (like model etc)

Could be useful also add much criteria to search the exact item to add

Kind Regards

Stefano

In shared service desk structures, it is necessary, depending on the context, in which case I include mine, the issue of departments sending tickets to each other, however, the use of the group could solve this, but it makes it impossible to manage the others elements such as contracts, assets, budgets and others, in which case the entity becomes vital. Therefore, having a simpler option for the non-IT attendant becomes necessary for ticket transfer. The current transfer focuses a lot on a technical part, but GLPI is evolving beyond the IT area, so other features seem to be needed. Obviously this is an opinion, which aims to join the group and build a collective idea.

Greetings