Plugin Ressources 4.0.14 – anomalies multiples sous GLPI 11.0.6

[Samirsncf]

Contexte
GLPI : 11.0.6
Plugin Ressources : 4.0.14
Environnement : DEV

Dans le cadre de tests de migration depuis GLPI 10 (plugin Ressources 3.0.7) vers GLPI 11 (plugin Ressources 4.0.14), plusieurs comportements inattendus ont été observés avec le plugin Ressources.

Problèmes constatés
1. Filtre sur les encadrants

Lors de la sélection d’un profil dans le champ "Sélection des encadrants directs" (ex : Managers), le filtre ne s’applique pas.
Tous les utilisateurs sont affichés au lieu d’être filtrés selon le profil sélectionné.

2. Liaison Département / Services lors de la création
Sur les utilisateurs existants : fonctionnement correct (relations OK entre Département, Services, Postes).
Lors de la création d’une nouvelle arrivée :
→ Après sélection d’un département, aucun service n’est proposé.
→ La configuration a été vérifiée et n’a pas été modifiée.

3. Encadrants non affichés
Sur les utilisateurs existants, la liste des encadrants ne remonte pas.

4. Champ "encadrant direct" non obligatoire
Même lorsque le champ "encadrant direct" est configuré comme obligatoire, il n’apparaît pas comme tel dans le formulaire.

5. Erreur sur l’annuaire des ressources

Lors de l’accès à "Annuaire des ressources", une erreur s’affiche :

"Une erreur est survenue"

Résultat attendu
Application correcte du filtre sur les encadrants selon le profil sélectionné
Remontée des services après sélection d’un département lors de la création
Affichage correct des encadrants existants
Prise en compte du caractère obligatoire du champ "encadrant direct"
Accès fonctionnel à l’annuaire des ressources
Informations complémentaires
Les anomalies n’étaient pas présentes (ou pas toutes) sur la version utilisée en GLPI 10 (plugin 3.0.7)
Une issue avait déjà été remontée concernant le champ "encadrant direct" sans retour à ce jour
Reproductibilité

Les problèmes sont reproductibles systématiquement sur l’environnement de test.

N’hésitez pas à me dire si des logs ou des informations supplémentaires sont nécessaires.
Par ailleurs, Avez-vous rencontrer le soucis de votre coté ?
Merci pour votre aide.

[tsmr]

For annuary error, thanks to tell me if you have logs (php-errors)

[Samirsncf]

Hello,

I found the PHP error generated when opening "Resources directory".

Here is the related log entry:

[2026-03-30 14:54:16] glpi.CRITICAL:   *** Uncaught PHP Exception TypeError: "DbUtils::getClassForItemtype(): Argument #1 ($itemtype) must be of type string, null given, called in ./src/DbUtils.php on line 555" at DbUtils.php line 529
Backtrace :
./src/DbUtils.php:529
./src/DbUtils.php:555                              DbUtils->getClassForItemtype()
./src/autoload/dbutils-aliases.php:171             DbUtils->getItemForItemtype()
./src/Glpi/Search/Provider/SQLProvider.php:6843    getItemForItemtype()
./src/Glpi/Search/Provider/SQLProvider.php:5265    Glpi\Search\Provider\SQLProvider::giveItem()
./src/Search.php:328                               Glpi\Search\Provider\SQLProvider::constructData()
./marketplace/resources/src/Directory.php:267      Search::constructData()
./marketplace/resources/front/directory.php:59     GlpiPlugin\Resources\Directory::showList()
...Glpi/Controller/LegacyFileLoadController.php:64 require()
./vendor/symfony/http-kernel/HttpKernel.php:181    Glpi\Controller\LegacyFileLoadController->__invoke()
./vendor/symfony/http-kernel/HttpKernel.php:76     Symfony\Component\HttpKernel\HttpKernel->handleRaw()
./vendor/symfony/http-kernel/Kernel.php:208        Symfony\Component\HttpKernel\HttpKernel->handle()
./public/index.php:71                              Symfony\Component\HttpKernel\Kernel->handle()

It seems that a null itemtype is passed when opening the Resources directory, which triggers a TypeError under GLPI 11.

If needed, I can provide additional context or perform more tests on my DEV environment.

[tsmr]

Yes i cannot use only this log for debug.

You can try to drop colums from /front/config.form.php (default columns)

[Samirsncf]

Hello,

Thank you for your help and your previous reply.

I investigated further based on the PHP error:

DbUtils::getClassForItemtype(): Argument #1 ($itemtype) must be of type string, null given

From the stack trace, the issue occurs when accessing the Resources directory and goes through:

Search::constructData()
Directory.php

Looking at Directory::rawSearchOptions(), it seems that some search options (columns) may not define an itemtype, which could result in a null value being passed to DbUtils::getClassForItemtype() under GLPI 11.

Regarding your suggestion to “drop columns”, I am not entirely sure how to proceed:

Do you mean modifying the plugin source code (e.g. in Directory.php)?
Or is there a way to disable/remove these columns from the plugin configuration / UI?

At the moment, I don’t see how to remove these columns from the interface.

I would prefer not to modify the plugin PHP files locally, as I am using the official version and want to keep a clean and supported environment.

However, to clarify my main concern:

The issue with accessing the Resources directory is not blocking for me, as I have alternative ways to access the data.

The main blocking issues for us are:

When creating a resource, the link between Department / Service / Position does not work (no service is displayed after selecting a department).

GLPI 11 4.0.14:

GLPI 10 3.0.7:

The managers list does not filter users based on the selected profile (all users are displayed).
Managers are not correctly displayed for existing resources.

These functionalities are essential for our daily use of the plugin.

I can of course:

reproduce the issues consistently
test configuration changes from the UI if applicable
provide additional logs or details if needed

Thanks again for your support, and please let me know how you would like me to proceed.

[tsmr]

The main blocking issue is already corrected : #145

[Samirsncf]

Hello Marc,

Thank you, I have applied the fixes from the commit and there is indeed an improvement. I have manually retrieved and replaced the 4 files modified in commit 4cb58b1.

The manager field is now correctly set as mandatory and the rule is properly taken into account.

At this stage, I have two different cases:

1. Existing resources

the manager field filtering works correctly and properly filters based on the manager profile defined in the configuration;
the department / service link is also working as expected.

2. New resources

it is still impossible to link department and service;
the service field remains empty, which prevents me from testing the position field (postes), as it depends on the selected service;
the manager field is now mandatory, but it still does not filter based on the configured manager profile and instead displays all users.

Thank you again for the fixes already provided, and for your help regarding the remaining issues on new resources.

[tsmr]

Try clean your glpi cache

And who is Marc ? :D

[Samirsncf]

Hello Xavier,

Oops, my mistake 😄 I mixed up the names — Marc opened another issue I was following earlier.

Following your suggestion, clearing the GLPI cache (files/_cache and files/_sessions) resolved the previous issues:

• the manager field is now correctly filtered based on the configured manager profile,
• the department / service linkage is now working properly.

However, I am now facing another issue during the creation of a new resource:

• I have a rule configured to hide certain fields (such as "Specialty" and "Contract type"),
• these fields are still visible in the form,
• they cannot be filled, but they remain displayed,
• this behavior only occurs when creating a new resource (wizard), not on existing resources.

Let me know if you need additional details or tests.

Thanks again for your help.

[tsmr]

Hello

Sorry but i have the same rule :

and the fields are hidden on the form

[Samirsncf]

Hello Xavier,

Thanks for your feedback.
On my side, I managed to fix the issue by applying the following change in the Twig template.

Before

The child fields were only controlled by the parent condition:

{% if hidden.plugin_resources_resourcesituations_id is not defined %}
{% if item.isField('plugin_resources_contractnatures_id') %}
...
{% endif %}
{% endif %}

and

{% if hidden.plugin_resources_ranks_id is not defined %}
{% if item.isField('plugin_resources_resourcespecialities_id') %}
...
{% endif %}
{% endif %}

So the visibility of these fields depended only on the parent fields.

After (my fix)

I added explicit checks directly on the child fields:

{% if hidden.plugin_resources_contractnatures_id is not defined %}
{% if item.isField('plugin_resources_contractnatures_id') %}
...
{% endif %}
{% endif %}

and

{% if hidden.plugin_resources_resourcespecialities_id is not defined %}
{% if item.isField('plugin_resources_resourcespecialities_id') %}
...
{% endif %}
{% endif %}

Result

After this change, the "Contract nature" and "Speciality" fields are now correctly hidden during resource creation on my side.

What I find a bit surprising is that the issue is not reproduced on your side with the same rule, so there might be a context/config difference somewhere.

Let me know if you want the full file or more details.

Thanks again for your help 👍