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,

INITIAL OBSERVATION

The Rules engine for assigning an item to an entity stops at the first rule checked, so it can't automate several actions to follow, each with its own type of criteria. The Business Rules engine for assets can do this, but the types of criteria and actions are limited. As for the Dictionaries engine, it can only act on the same type of data as the criterion. All this works very well, but lacks the flexibility to write richer rules.

SUGGESTED DEVELOPMENT

Can we expand data types available in criterion on business rules actions for assets?

Examples of additional criterion types :

• Name
• Model
• or any type of data that GLPI-Agent can retrieve
•  ...

Examples of additional action types :

• Assign group
• Assign Computer type, Printer type, Monitor type ...
• ...

CASE STUDIES

For example, I'd like a regular expression on the Computer Name to define an Inventory Number, and another regular expression on the same Computer Name to define the Group in Charge.

Example: a Computer named XXX-A-123456 will have the Group in Charge A and the Inventory Number 123456 (a rule for assigning an item to an Entity is already based on the code XXX).

I also want a criterion on the Model of a Computer (or Printer, Network Device, Monitor, etc.), possibly associated with its Manufacturer, to define its Type.

Examples:

• if a Computer Model contains the expression AIO or iMac, then its Type is All-in-One
• if a Computer Model contains the expression book, then its Type is Portable
• if a Printer Model contains the expression ColorLaserJet, then its Type is Color Laser Printer
• if the Manufacturer of a Monitor is Epson and its Model begins with EB, EF, EH or CO, then its Type is Video-projector.

If you're interested in this suggestion, do you think this development is possible?

Thank you.

Note: this post is translated from french with DeepL Translate and was also posted in french on the GLPI-Project forum :

https://forum.glpi-project.org/viewtopic.php?id=289646

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.

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

When synchronizing users, adding new ones, there is no possibility of limiting to the selected OU. It would be desirable to be able to set the base DN (BaseDN) from where, with the filter set, new / old users from AD / LDAP would be downloaded / updated.

As is possible with the GUI.