Do not list agentless agents and restrict agents by Task entity on Actor Taskdropdown

[eduardomozart]

After a successful ESX inventory task, an agent is created on GLPI. Into glpi-project/glpi-agent#832 I discussed with @g-bougard about this behavior (the reasons and possible workarounds that could be implemented on the GLPI-Agent is discussed there). He said that it's an inherited behavior from FusionInventory Agent and I should open an issue on GLPI-Inventory plugin. From GLPI server point-of-view, doesn't seems to be a way for it to determine that it's an agentless inventory instead of a inventory of a real machine and for this reason it seems to create an agent. I don't see any problem with it at all, but when creating tasks, those agentless agents are shown into the dropdown of task actors, but they doesn't have any capability to run those tasks. Into the glpi_agents DB, the only way I could find to differentiate those agentless agents are using the version and use_module_* columns. Since the version column of these agents are NULL, we can use it to hide those agentless agents as task actors. Other possible solutions for this is using the use_module_* column, which would allows us to be much more specific about the filter and features that an agent is capable of. We could improve the method isAgentCanDo to also fetch the value of those columns and only return true if the module is enabled (current behavior) and also if it's installed on the agent. The getAgentsCanDo also returns information about the agents and maybe could be used to replace this SQL query, and the use_module_* values are also available into the returned array object that could be checked.

With this fix applied, only two agents are returned:

Even when there's three agents available (ESXi is an agentless agent):

Maybe we could hide non-version Agents from Administration > Inventory > Agents too.

Checklist before requesting a review

Please delete options that are not relevant.

• I have performed a self-review of my code.
• I have added tests (when available) that prove my fix is effective or that my feature works.
• This change requires a documentation update.

Description

• It fixes # (issue number, if applicable)
• Here is a brief description of what this PR does

Screenshots (if appropriate):

[stonebuzz]

@g-bougard can you confirm that the agent created in GLPI for assets that have had an inventory via a remote agent, comes back with a null version?

I don't know if it's a good idea to use this where clause (could return false positives).

Perhaps there should be a dedicated flag in the agents?

[g-bougard]

Actually, I would say this is only true for ESX inventory. And I can say this is not true for inventory generated via RemoteInventory task.

And indeed, this is probably and error to not include that VERSION data in ESX inventory.

So IMHO, I think it's a bad idea to rely on a missing "version" field to filter out that dropdown as this is not on purpose semantically.

Checking a task module is enabled for the currently edited task is probably a better way of doing. I just hope this couldn't involve unexpected side-effects.

[stonebuzz]

Thanks for your reply @g-bougard

In the meantime, we're going to think about getting more relevant information from GLPI (so that we can filter the list of agents from the plugin).

As things stand (and for the proposed solution), relying solely on the ‘null’ version value doesn't seem to be a wise choice.

using the use_module_* column seems more coherent.

Best regards

[eduardomozart]

Hello @stonebuzz and @g-bougard,
Now this PR checks the use_module_* columns to determine if an actor should be shown on Actors dropdown. If it's not possible to determine if it's module is enabled or not ($moduleactive isn't set), e.g. a new module is added, it will keep the current behavior and display all agents.

[eduardomozart]

Hello guys,
You've seem missing on the last two days, hope you're ok.
I did some refactor on the modulesactive code to make the SQL easier to read and also introduced the filter by entity.
Now if the agent doesn't belong to the task entity it's not shown on dropdown. To keep the current behavior (show all agents independent of the entity it belongs) users must create tasks on the Root entity. By default the agent seems to be assigned to the same entity that it's Computer asset entity belongs.