No org_id linked to 'Network Interface'

[dariocodes]

The extension works fine however when you try to filter an organization within itop you'll notice that even when you apply a filter all network interfaces will still be visible to all organizations. I fixed this by adding an org id to network interface class in the datamodel of itop and then manually add the org_id in the presentation for all network interfaces in your extension. I'm creating a pull request as we speak for the itop side of the issue.

[Hipska]

I think best would be to add an AttributeExternalField named org_id to retrieve the org from the parent CI as I don't think there will ever be a situation where the interface is managed/owned by another org than the CI's org?

[dariocodes]

Your idea is probably a better solution as in my solution you would have to manually enter the CI and organization which could potentially create conflicts. Do you think the class id="networkinterface" in the datamodel of itop should then also inherit the organization from the CI it is assigned to @Hipska ?

[Hipska]

As soon as you want to filter them by org, yes. NetworkInterface doesn't have a CI linked, it needs to be done on PhysicalInterface, LogicalInterface and FiberChannelInterface from iTop and NetworkDeviceVirtualInterface from this extension.

PS, you are welcome on Slack in the #teemip channel to discuss as well..

[Hipska]

I do believe the datamodel in itop should then be changed to attribute the external field to the NetworkInterface.

That doesn't make sense, as each of the subclasses points to a specific FCI subclass (resp ConnectableCI, VirtualMachine and DatacenterDevice). Besides, it would also be a too big datamodel change with breaking changes and would never get accepted.

[xtophe38]

Hi guys,

Sorry for the late answer.

As you already expressed, none of the interfaces that derive from the root NetworkInterface class (let's call them Network Interfaces as you did) can be filtered by organizations, which makes them all visible to any user that has a read access to these classes, regardless its allowed organizations. I do understand and acknowledge that this may be a problem.

This situation never seemed to cause an issue to TeemIp users up to now but it may be the right time to look after it (fix it ?). I like @Hipska proposal to add an AttributeExternalField named org_id. Beside its simplicity, it shouldn't hurt too much the current implementations.

So, let me add this to my TODO list. I'll work on it in the coming weeks and that external field should be visible in next TeemIp's revision (sooner in GitHub repos).

[xtophe38]

Change has been done an committed.

[Hipska]

@xtophe38 can you reference the PR for this please (or the commit)?

[xtophe38]

OK, @Hipska: done in commit 6f6b31d