No inventory number generated when importing computers from ocsngfullsync script

[scoudeville]

I'm using ocsngfullsync script to automatically import computers from OCS to GLPI. Since I used manual sync with OcsInventory NG plugin, there was no problems.

Now, computers are correctly imported by user "ocsinventoryng" and no inventory number is created. I have to select new computers, Mass Action, and generate a new one to get to success.

I've already created a "ocsinventoryng" local user in GLPI, with "super-admin" profile on root entity (and recursive) , but it doesn't help.

I don't think it's a OcsInventory NG plugin problem because it's using correct GLPI method to insert computers, like in manual sync process.

I think GenInventoryNumber plugin doesn't react if it's loaded from CLI, but can't get any log to help.

[scoudeville]

GLPI v 0.90.1. Plugin version 9.1+1.0. OCS Inventory NG plugin version 1.2.1

[btry]

Hi

It seems the same when an asset is created by Fusion Inventory.

[fralla2]

Hi @btry , do you know if the preItemAdd function in https://github.com/pluginsGLPI/geninventorynumber/blob/d5e3fc52ff7420c50fea987797e69a9f104fdb6f/inc/generation.class.php#L84 is called before every itemadd (even the ones from OCS Inventory and FusionInventory) ? Or should a hook like "autoinventory_information" should be added for this plugins to work?

If this function is called even if it's a plugin that add the item, I suspect that both plugins (OCS and FusionInventory) are just missing rights to CREATE and UPDATE fron those 2 lines :

_Session::haveRight("plugin_geninventorynumber", CREATE)_ https://github.com/pluginsGLPI/geninventorynumber/blob/d5e3fc52ff7420c50fea987797e69a9f104fdb6f/inc/generation.class.php#L88

_Session::haveRight("plugingeninventorynumber", UPDATE) https://github.com/pluginsGLPI/geninventorynumber/blob/d5e3fc52ff7420c50fea987797e69a9f104fdb6f/inc/generation.class.php#L116

Can you point me if my suspicions are in the right direction?

Thanks Francois

[btry]

Hi

preItemAdd is a hook. You will find the hook definition in this plugin in hook.php.

To find when the hook is called, read CommonDBTM::add().

https://github.com/glpi-project/glpi/blob/9.5/bugfixes/inc/commondbtm.class.php#L1120

[fralla2]

After some more troubleshooting :

• The function PluginGeninventorynumberGeneration::preItemAdd get called, so the hook is working correctly
• It passes the first filter _if (in_array(getclass($item), PluginGeninventorynumberConfigField::getEnabledItemTypes()))
• It doesn't have "CREATE" right on the plugins : _if ((!Session::haveRight("plugingeninventorynumber", CREATE)))
• It's not detected as isCommandLine : if (!isCommandLine()) So it triggers exception : Session::addMessageAfterRedirect(__('You can\'t modify inventory number', 'geninventorynumber'), true, ERROR);

Is-it a normal behavior for fusionInventory not to get detected as a commandline ?

[btry]

Hi

You should check how the OCS to FI script do the import. Maybe it issues an HTTP request to FI.

An easy way is to check the access log of the http server in real time, then run the script.

[fralla2]

Yes the fusionInventory agent (and I'm pretty sure OSC does the same) are sending HTTP POST requests to FusionInventory plugins...

IPADDRESS - - [01/Oct/2021:15:55:04 -0400] "POST / HTTP/1.1" 200 57 "-" "FusionInventory-Agent_v2.6" IPADDRESS - - [01/Oct/2021:15:55:09 -0400] "POST / HTTP/1.1" 200 57 "-" "FusionInventory-Agent_v2.6" IPADDRESS - - [01/Oct/2021:15:55:16 -0400] "POST / HTTP/1.1" 200 98 "-" "FusionInventory-Agent_v2.6" IPADDRESS - - [01/Oct/2021:15:55:20 -0400] "POST / HTTP/1.1" 200 98 "-" "FusionInventory-Agent_v2.6"

Since the device is added directly by the "Plugin_Fusioninventory" user once the inventory is submitted by http request, I think we could add another if and verify that the user is not it before throwing the error... That should fix the issue...

I've already tested with commenting this check and the inventorynumber gets generated correctly on computer creation from FusionInventory...

I'll have a look on monday and submit the fix for approval

[fralla2]

https://github.com/pluginsGLPI/geninventorynumber/blob/d5e3fc52ff7420c50fea987797e69a9f104fdb6f/inc/generation.class.php#L88

Changing this line for the following fix it for us.... I don't know if you want to submit this change to the community, it should also fix it for OCS Inventory since it uses FusionInventory for GLPI plugins...

I not sure if the OP @scoudeville could test if it fix for him too (4 years later....)

if ((!Session::haveRight("plugin_geninventorynumber", CREATE)) && $_SESSION["glpiname"] != 'Plugin_FusionInventory') {

[btry]

Hi

You may also want to check if the user Plugin_FusionInventory has a profile and simply grant the right to generate a inventory number. This would avoid to hard code a username.

[fralla2]

That was my first thought because I too hate to put a hardcoded string name inside code but this account has no profile associated with it by default.

I've associated the "super-admin" profile temporarily for testing (which already have CREATE and UPDATE rights on this plugins) but it did not seem to pass the Session:haveRight() check and was the reason I was asking if it's normal that it's not detected as a commandLine...

For info :

• Session::haveRight("plugin_geninventorynumber", CREATE) : Returns false (even with the super-admin profile)
• isCommandLine() : Returns false
• isCron() : Returns false

The other thing is, since it's a function user created by the FusionInventory plugins itself, and that user normally don't "log-in" in GLPI and we don't have control over it's password, I don't want to give it lots of rights so if we would be to find a fix for the "haveRight()" check, we would have to create a profile manually with restricted rights only for generation of the inventoryNumber.....

Not convinces it would be user friendly.....

Your thoughts?

[fralla2]

PS Thanks @btry , not sure we say it frequently enough but you really do a great works for this tool ;)

[btry]

The right to relate an inventory number is specific to the plugin, then super admins don't have this right by default, except if the plugin has logic to add this right at installation time.

Adding a profile to the fusion inventory user might not work as I guess the plugin artificially configure the session to do some kind of fake login, just enough to let glpi believe someone is logged in, without setting up an active profile. If I'm wrong, then tuning the rights should be sufficient, and ensuring that the account is disabled in GLPI should prevent anyone to login. An testing instance of glpi + FI are necessary to validate the inability to login, after setting the password to some known value.

[fralla2]

For infos :

• The right for "CREATE" and "UPDATE" for "plugin_geninventorynumber" was given by me to the super-admin profile prior to testing because we needed super-admin users to be able to generate and update this field.

• I tried adding the super-admin profile to "Plugin_FusionInventory" user at first without luck so I'm pretty sure your deductions are right in that FusionInventory never really log-in but artificially create a session just so that there is some logging for his actions (adding computer or devices, updating, etc)

I might investigate further later when I'll have some spare time but don't really have time this week and I won't be messing too much on our live instance. We already have a test instance but no devices configured to send the fusioninventory to it yet.

The hard-coded fix does it for us for the moment because we needed this inventoryNumber automatically generated for my homemade plugins to be able to print asset labels on our devices. (might publish it later after lots of cleaning...)

Thanks again Francois

[czernedo]

Hello,

unfortunately we still have this issue with our GLPI 9.5.6, Inventory Number Generator Plugin 2.5.1 and OCS Inventory NG Plugin 1.7.3. I tried to set the rights for the plugins or the "ocsinventoryng" user but nothing really helped. When admins are creating new computer objects, the inventory number will get generated correctly. When OCS is creating new objects while running the ocsfullsync script unfortunately the inventory number field is blank and no number will be generated.

Is there any other workaround for this or will this issue be fixed in the near future? I hoped it will be fixed with the updates to support GLPI 10.0.0 but unfortunately there is nothing related in the changelogs.

Thanks, Dominik

[lfischer85]

I was able to get this to work with OCS inventory NG using the patch of 'geninventorynumber/inc/generation.class.php' that fralla2 mentioned above, just replacing the hardcoded username like this:

if ((!Session::haveRight("plugin_geninventorynumber", CREATE)) && $_SESSION["glpiname"] != 'ocsinventoryng') {