Import location hierarchy from LDAP Active Directory user

[corzakiewicz]

Code of Conduct

• I agree to follow this project's Code of Conduct

Is there an existing issue for this?

• I have searched the existing issues

Version

10.0.4

Bug description

Hi,

Our current GLPI is version 10.0.14
We have only one instance : Production.

LDAP Active Directory synchronization is set up on our GLPI server.
This allow to import users and to automatically create location mapping the AD User field "City". The automatic creation of locations using hierarchy methode (using the symbol > to specify the child and parent) was working great on GLPI v9.
We migrated to GLPI v10 on December 2023.
Today, I discovered new locations in GLPI have automatically been created the day after we migrated to GLPI v10.
It seems that GLPI is no more able to "interpretate" correctly the symbol > to create hierarchy in locations, so GLPI created new locations.

I have read an article that seems to be similar to this case but I don't understand what I have to do to solve this issue : #15812
In addition, I understood this "bug" was solved in v10.0.11 but as we are running a more recent version, I am confused.

Could you please tell me if the separator symbol > is still the one to user ?
If yes, how could I solve the issue ?

Thank you very much for your help.

Relevant log output

No response

Page URL

No response

Steps To reproduce

No response

Your GLPI setup information

No response

Anything else?

No response

[trasher]

Please try with latest stable release.

[corzakiewicz]

Thank you for your quick answer.
I'll try soon and I let you know :-)

[corzakiewicz]

Hi,
My GLPI has been updated to v10.0.15, unfortunately, the bug still occurs.
Do you have an idea on how I could solve this ?
Thank you.

[corzakiewicz]

Hi,
Do you need additional information from me to investigate ?
Thank you.

[trasher]

Could you try if #17187 does solve your issue? It's maybe not the final fix, but at least we can be sure it's the same as the inventory related one.

[cedric-anne]

@corzakiewicz

Could you check if #17187 solves your issue?

[trasher]

Someone else has confirmed the fix works for users and inventory

[corzakiewicz]

cedric-anne commented 35 minutes ago
@corzakiewicz

Could you check if #17187 solves your issue?

---

Hi,

I am still looking for how to proceed to apply this patch. Do I have to replace the files Inventory.php and CommonTreeDropdown.php ? Is there a way to find their path ?

Thank you.

[corzakiewicz]

I have just tried after replacing the two mentionned files.
The location import does not work anymore, here is an error in sql-errors.log file :

[2024-06-04 13:36:58] glpisqllog.ERROR: DBmysql::doQuery() in /var/www/glpi/src/DBmysql.php line 403
*** MySQL query error:
SQL: UPDATE glpi_users SET date_sync = '2024-06-04 13:36:57', locations_id = '-1', date_mod = '2024-06-04 13:36:57' WHERE id = '529'
Error: Out of range value for column 'locations_id' at row 1
Backtrace :
src/DBmysql.php:1503 DBmysql->doQuery()
src/CommonDBTM.php:689 DBmysql->update()
src/CommonDBTM.php:1698 CommonDBTM->updateInDB()
src/AuthLDAP.php:2970 CommonDBTM->update()
src/AuthLDAP.php:398 AuthLDAP::ldapImportUserByServerId()
src/MassiveAction.php:1420 AuthLDAP::processMassiveActionsForOneItemtype()
src/MassiveAction.php:1398 MassiveAction->processForSeveralItemtypes()
front/massiveaction.php:62 MassiveAction->process()
public/index.php:82 require()
{"user":"422@GLPI-V10"}

[cedric-anne]

I take a quick look at the code. Is it possible that your LDAP is returning a non empty value that contains on spacing chars and/or > for the location field ?

[corzakiewicz]

Indeed, location field in our LDAP contains spacing chars and the character ">" as separator to specify the hierarchy
This has been like this from the beginning we setup GLPI 4 years ago and was working well since recently

[cedric-anne]

Indeed, location field in our LDAP contains spacing chars and the character ">" as separator to specify the hierarchy This has been like this from the beginning we setup GLPI 4 years ago and was working well since recently

What is the exact value ? We could add a test for it in our test suite.

[corzakiewicz]

The exact value is :
Mycompanyname Agences>Caen

PS : I have switched the company name for privacy reason

[corzakiewicz]

Hi,

I have seen this morning that invetory does not work anymore since I applied the patch on June, 4th.
So, I have just moved back to the previous version of files inventory.php and CommonTreeDropdown.php and it works correctly now.

When it did not work, here is the error message I found in php-errors.log :

glpiphplog.CRITICAL: *** Uncaught Exception Error: Class "InventoryTestCase" not found in /var/www/glpi/front/inventory.php at line 48
Backtrace :
index.php:93 include_once()
public/index.php:82 require()

[trasher]

Sounds like you made something wrong.

[trasher]

The only relevant changes to apply are ones on src/CommonTreeDropdown.php. Or you can test with nightly build.

It's a bad idea to put a patch test on production if you're not 100% sure what you are doing.

[corzakiewicz]

Sounds like you made something wrong.

I totally agree.
I asked for some more information about how to proceed to apply these patch but I got not answer :-( So I tried to apply anyway, which is a bad idea as you mentionned.
If you agree, please give a quick explaination to me on how to apply the patch, then I will be a little more "skilled" on it :-)
Thanks again for your help.

[trasher]

There are tons of docs about aplying patches; this differs regarding of your environment. You can also just consider applying the few lines changes by hand.

[corzakiewicz]

That's clear, thank you very much👍

[CLcdiazp]

Hello everyone, raise a ticket to GLPI
#17304
with the following:

In the LDAP server configuration for users, the default settings include the following AD attributes:"
Surname: sn
Email: email
Given Name: givenname
Title: title
The root rule is:

Global Criterion - LDAP Server is Server Name
Actions: Action Entity assign Entity > Subentity
This ensures that when the LDAP is synchronized, the username, Surname, Email, and Title are synchronized in the subentity, and this process works correctly.

However, when adding a location attribute configuration:

Surname: sn
Email: email
Given Name: givenname
Title: title
Location: l
Upon synchronization, the location is loaded into the root of the entity rather than the subentity.

When checking the root rule, I noticed that the location criterion is missing from its criteria.

LDAP Criteria:

(AD)User ID
(LDAP)MemberOf
(LDAP) Title
(LDAP) Common Name
(LDAP) Department Number
(LDAP)DistinguishedName
(LDAP) Email
(LDAP) Employee Number
(LDAP)Manager
(LDAP) Organization
(LDAP) Telephone Number
(LDAP) User ID
Object Class
Therefore, if I add the parameter l in the LDAP server's location, it will load it into the root entity, which has caused a problem for me.

I'm not sure if this is a bug.

Let me know if you need any further assistance!

His response was This issue has been closed as we only track bugs here.

So if it is not a bug, where can I request this improvement for the next version of GLPI?

[trasher]

So if it is not a bug, where can I request this improvement for the next version of GLPI?

On suggestion website.