Hello,

Imagine you have plenty of end-users with rights only on the self-service (=simplified) interface.

Imagine you have plenty of entities, and end-users have only 'post-only' rights on one of theses entities.

The need is to give the possibility to end-users to view (and depending on rights to edit) tickets for which they don't have the formal rights (different entities) when and only when they are assigned as watchers on these tickets.

Example:

Two users: U1 and U2 have respectively 'post-only' rights on entities E1 and E2. Let's create one ticket T1 in entity E1 with U1 as requester. In this case U2 cannot see (nor edit) T1. In this case T1 can't be seen by U2 (we can't even assign U2 as watcher due to entity restrict).

1) we would like to be able to assign any user (whatever entity rights he may have) as watcher.

2) we would like to permit U2 to be able to view and add followups to T1.

More:

Of course this should also be possible via groups as watchers. When users belonging to a group (assigned as watcher on T1) don't have formal entity rights.

This need can be linked to the 'carbon copy' of users at ticket creation: when a user is creating a ticket he/she may add any other user to be watchers (independently of entities).

Thank you,

Regards,

Tomolimo

Il serait pratique de colorer une tâche dans le calendrier en fonction de la priorité du ticket auquel elle est associée

I think that multi chronometer for tasks. The intension is a better control
of task. Multi tasks running at the same time. exemple Stop the task 1 e
continue the task 2.

Some times the user call e dont have ticket. I could start the chronometer
and when stop i would have the option to create a ticket.

Request:

• Create a new category - subsciption plans
  
• Add a field or tab in the Lines menu of a specific number to assign subscription plans.
• Include customizable details like plan name, cost, features, and duration.
• Enable filtering and reporting based on subscription plans.

Benefits:
Improves telecom subscription management, reporting, and resource tracking.

Today in the Administration > Inventory menu, we have 2 ways of interacting with equipment through the status that would be considered a life cycle of the equipment as a whole

The first of them, the clearest, is the default status, perfect, it is applied to practically all classes of devices that have direct inventory (Agent + SNMP): Computers, Printers and Network Device

And the second way in the same menu, at the end of the page, is called "Agent cleaning", using the "Change status" action
Today this second menu works only for computers, although the default status is applied to computers, printers and network devices

My suggestion would be to include these 2 types of device: Printer + Network Device, so that this menu could change its status, just like it already happens with computers

Or that this option was created right below this same menu, allowing you to select whether or not to use these other inventories as an option.

The logic behind this is that if the computer is necessary to have a certain level of control over its life cycle automatically, because printers and network devices that already come from SNMP inventories cannot also have the same support.

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

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