Cara pinjaman online silahkan hubungi layanan 0852-1165-7059.proses cepat tanpa anggunan 

Cara pembatalan kredit pintar

hub.Wa 0852-1165-7059.layanan kami siap membantu anda 

Pembayaran pinjaman kredit pintar Hb.Wa(0852-1165-7059) jelas masalah anda di tim kami 

Customer support dukungan indodax hubungi ☎️0878 537800 72☎️ atau nomor alternatif layanan 021-[00989500] 

Untuk mengatasi kendala gagal deposit indodax hubungi Chanel ☎️ 0878 53 780 072☎️📩021-50959800☎️ Di pasti kan verifikasi virtual account Bank yang terdaftar dalam selalu aktif dan mencukupi nominal yang akan didepositkan Agar bisa di akses kan dari sistem informasi pelayanan indodax dalam arahannya customer service indodak dapat bantuan pelayanan indodax 

Deskripsi : Cara Membatalkan 𝐏engajuan P𝐢njaman Sp𝐢njam 𝐒𝐇𝐎𝐏𝐄𝐄. Pembatalan Dengan Cara menghubungi layanan Live Chat Via WA(0821_9669 1515, , jelaskan dengan baik alasan ingin Melakukan Pembatalan , dan ikuti langkah-langkah Pembatalan yang di instruksika

I am part of the Development Team. While configuring GLPI version 11, I noticed that as a normal user, I am able to view the asset details of all users in the ticket section.

I would like to restrict this functionality. My requirement is:

• When a user creates a ticket, they should only be able to view their own asset details.

• If a ticket is raised on behalf of another user, the corresponding user’s asset details should be automatically linked or assigned to that ticket.

Is this configuration possible in GLPI? Could someone please guide me on how to achieve this?

Our situation is probably a less common one. I'm testing GLPI in our organisation to see if it's a good fit for us.

I haven't seen this option to be available elsewhere, but we would definitely benefit if an option as the following would be implemented.

Our IT Helpdesk mostly helps existing clients, but sometimes an unknown person asks our Helpdesk for help. It would be great if the Helpdesk could create users. I can already give them create users permissions, but if I give them this permission, they are also allowed to create other Helpdesk users, which is something I don't want. I've created a Profile specifically for SSP users and my Helpdesk colleagues get an account with the Helpdesk Profile. I would like to limit helpdesk employees to only be able to create users with the SSP profile.

If this is already possible, I can't find the option.

Edited because there was something wrong in my earlier statement.

When using Ops tools such as Ansible to install/manage GLPI we can use the Console (`bin/console`) to perform some configuration using the "config:set" command.

But when, setting a secret such as the inventory credentials ("basic_auth_password" key in "inventory" context) we must provide it encrypted because the console will store it as-is in database and application expect it to be encrypted when it'll fetch it from there.

For example the following command:

bin/console \
    config:set \
    --context=inventory \
    basic_auth_password \
    secret_password

Will create/update the following row in `glpi_configs` table:

+-----+-----------+---------------------+-----------------+
| id  | context   | name                | value           |
+-----+-----------+---------------------+-----------------+
| 420 | inventory | basic_auth_password | secret_password |
+-----+-----------+---------------------+-----------------+

SQL query:

SELECT * FROM `glpi_configs` WHERE `context` = 'inventory' and `name` = 'basic_auth_password';

While setting this password via the GUI (path = "/Inventory/Configuration") creates/updates the following row in `glpi_configs` table:

+-----+-----------+---------------------+---------------------------------------------------------------------------+
| id  | context   | name                | value                                                                     |
+-----+-----------+---------------------+---------------------------------------------------------------------------+
| 420 | inventory | basic_auth_password | abcdefghijklmnopqrstuvwxyz0123456789+abcdefghijklmnopqrstuvwxyz0123456789 |
+-----+-----------+---------------------+---------------------------------------------------------------------------+

Having a new command to call GLPIKey::encrypt() directly such as, for example:

bin/console security:encrypt secret_password
# Returns:
# abcdefghijklmnopqrstuvwxyz0123456789+abcdefghijklmnopqrstuvwxyz0123456789

We could use it like this:

bin/console \
    config:set \
    --context=inventory \
    basic_auth_password \
    "$(bin/console security:encrypt secret_password)"

### Problem

Currently, Business Rules for tickets in GLPI allow conditions based on field values (e.g., *is*, *is not*, *contains*, etc.).

However, there is no comparison operator such as:

> **"was changed"**

This makes it impossible to trigger a rule only when a specific field value has actually been modified.

At the moment, rules are executed whenever a ticket is saved, even if the relevant field was not changed.

---

## Use Case

A rule should be executed only if:

- The **Category** of a ticket was changed

- The **Priority** was modified

- A specific **custom field** value was updated

### Example Scenario

If the ticket category changes from *Hardware* to *Software*, then trigger reassignment or notification.

If the category remains the same, the rule should not run.

---

## Proposed Solution

Introduce a new comparison operator in Business Rules:

```

Field → Comparison → Value

Category → was changed → (no value required)

```

### Optional Extended Functionality

```

Category → changed from → [old value]

Category → changed to → [new value]

```

---

## Expected Behavior

The rule should execute only when:

- The selected field value differs between the previous and the current state of the ticket.

The rule should not execute when:

- The ticket is saved without modifying that specific field.

---

## Benefits

- More precise automation

- Avoid unnecessary rule executions

- Better control in complex workflows

- Potential performance improvement when many rules are configured

---

## Additional Context

This feature would enhance workflow precision and improve the flexibility of Business Rules in environments with complex automation requirements.