Search.php regex is preventing results from being parsed correctly in UI

[DonutsNL]

Hi,

Im not sure its a bug, or on purpose. Either way, it looks like the expression shown from the Search.php is failing when numbers are used in the namespace. Currently this condition does not generate any obvious errors, just a table with an row count that is equal to the ammount or rows in the database bit without the actual values. The fields are rendered correcly in the search filters but not shown in the tablerows. Filtering works (less rows) but again without any data in the roe colums.

As a fix I will be renaming all namespaces but some additional documentation on the wiki Search() / DBTM might be helpfull for other developers.

It also feels a bit weird in the current implementation doent allow numbers in the plugin namespaces. This might also introduce issues in the future when vendor namespaces dont comply with this convention.

[cedric-anne]

Hi,

This limitation has been introduced in GLPI 9.4 by glpi-project/glpi#4802. Unless for genericobject (see pluginsGLPI/genericobject#247) and fields plugins (see pluginsGLPI/fields#306), I did not remember that anyone complains about it.

A proposal was made in glpi-project/glpi#5495 to remove this limitation. The PR was not accepted mainly because it was proposed on a bugfixes version, but I think it could be acceptable if the change targets the next GLPI major version.

[DonutsNL]

I can confirm that after renaming the objects function as described and expected.