NetXMS Support Forum

English Support => General Support => Topic started by: normalcy on May 03, 2024, 05:11:34 AM

Title: new desktop client - unbound nodes in infrastructure outside the folder tree
Post by: normalcy on May 03, 2024, 05:11:34 AM
I'm still primarily using the legacy console due to muscle memory and preferring how the object browser is not split into the different modules/perspectives like the new console. But I still load it up and check in on it every release to see how its coming along.

One thing I've noticed is that nodes discovered in the network that are not bound under a container in 'infrastructure services' show up outside of the infrastructure service folder heirachy.  Can't see a way to unbind them (as they have no parent container) if I don't want to track them. 

If I bind them to a container "unmonitored" they then move there and disappear.  Does this mean there should be a catch-all container for all nodes?  Or is this a bug?

The legacy console does not show unbound nodes anywhere (other than under their subnets in 'entire network').
Title: Re: new desktop client - unbound nodes in infrastructure outside the folder tree
Post by: Filipp Sudanov on May 03, 2024, 12:10:56 PM
It's planned to fix this so that if object is present somewhere else (e.g. under subnet tree) it won't be displayed in the root. But in cases when user does not has access to any container/subnet containing a node, but has access rights to the node itself, it would be display in the the root.

Currently you can have "Unbound stuff" container somewhere with this auto-bind script, it will pick objects that are not present in any other containers:

for(p : $object.parents) {
  println(classof(p));
  if ((classof(p) == "Container") and p.id != $container.id) return false;
}
return true;
Title: Re: new desktop client - unbound nodes in infrastructure outside the folder tree
Post by: normalcy on May 08, 2024, 08:38:16 AM
Quote from: Filipp Sudanov on May 03, 2024, 12:10:56 PMCurrently you can have "Unbound stuff" container somewhere with this auto-bind script, it will pick objects that are not present in any other containers:

for(p : $object.parents) {
  println(classof(p));
  if ((classof(p) == "Container") and p.id != $container.id) return false;
}
return true;

Thanks Filipp.  

I tried this script however it seems to pickup and autobind all nodes over time, not just those nodes outside the infrastructure services tree with no parent container.  

eg: attached an example of it filtered down to some APs that are already in parent containers and still trigger the autobind event.
Title: Re: new desktop client - unbound nodes in infrastructure outside the folder tree
Post by: Filipp Sudanov on May 10, 2024, 08:47:24 PM
Not sure why this is happening. Can you run the script I've shared manually (via Execute Script from context menu) on a couple of nodes which we bound to that container, but should not and share the output.
Title: Re: new desktop client - unbound nodes in infrastructure outside the folder tree
Post by: Victor Kirhenshtein on May 11, 2024, 10:59:09 AM
I just updated client application so that nodes without parent objects in infrastructure tree are not shown as root level objects. This change will be part of release 5.0.3.

Best regards,
Victor

Title: Re: new desktop client - unbound nodes in infrastructure outside the folder tree
Post by: normalcy on May 15, 2024, 05:16:46 AM
Quote from: Victor Kirhenshtein on May 11, 2024, 10:59:09 AMI just updated client application so that nodes without parent objects in infrastructure tree are not shown as root level objects. This change will be part of release 5.0.3.
Best regards,
Victor
Thanks Victor, look forward to it.

Quote from: Filipp Sudanov on May 10, 2024, 08:47:24 PMNot sure why this is happening. Can you run the script I've shared manually (via Execute Script from context menu) on a couple of nodes which we bound to that container, but should not and share the output.

Hi Filip, attached is a screenshot of executing the script on a node that had an existing parent.  It always seems to return true whether on a node that has no other parent or an existing node.