You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I just spotted something which is not accurate in my datamodel.
IP Devices - IP Phones should link ConnectableCIs instead of Network Devices.
Somehow this got mixed up. Right now, you can link the IP Phone to a switch, but you can't link the IP Phone to a PC (if IP phone is actually a small switch as well, which is often the case).
The problem is: IP Devices are not necessarily 'datacenter' devices. An IP Phone is both a network device and an end user device as well. I'm also not entirely happy with Network Device being subclassed as a DataCenter device.
This leads to multiple options, both with their ups and downs.
Option 1
We could provide an additional class which mostly imitates lnkconnectablecitonetworkdevice. A new class (and database table) would be needed. We could either make it quite limiting ( lnkconnectablecitoipdevice ) or generic ( lnkconnectablecitoconnectableci ).
Upside: not redefining any other original classes.
Major downside: if you want the link to appear on for example a PC's or other connectable CI's tabs, every one of those classes (or a parent class) needs a redefinition or additional tab.
Option 2
An alternative would be to make our abstract IPDevice class be a child of Network Device. Again, this has undesired effects, since you'd inherit rack options etc. Also, it does not make sense to have IP Camera, IP Phone listed as DataCenter device.
Upside: our IP Devices would be visible on the "Network Devices" tab of for instance a PC.
Major downside: a lot would need to be hidden, which is possible though, especially since I made IPDevice an abstract class with is used by IP Device (generic), IP Camera and IP Phone.
Option 3
Redefining the Network Device, so it's not part of DataCenter class. Question: create a subclass for network switches, to allow for rack options etc? When talking about switches, this might be very useful. When talking about wifi access points, you can have them everywhere in the building, which again questions the definition of 'what is a DataCenter device'.
Upside: actually makes most sense of all.
Major downside: safe for iTop's original IP Phone which never made sense to me (or many others it seems), I'm not in favor of redefining entire classes to change their position in the data model. When done, it's likely to cause quite some head aches to convert everything properly, since I'm sure most of us have used this a lot already.
Other options may be possible as well.
So it's mainly a discussion about the place of DataCenter Device vs Network Device, or other options to consider so you can link all kinds of connectable CIs to IP devices.
IMHO, Option 2 may be the cleanest approach, since our IPDevice class was already based on the Network Device class.
The text was updated successfully, but these errors were encountered:
redefines the IP Generic device and makes it a child of NetworkDevice after all
NetworkDevice is slightly redefined: Network Device type now allows NULL.
Raises new issue: the original Network Devices overview also lists all instances of our subclass.
jbostoen
changed the title
IP Devices - IP Phones should link ConnectableCI's instead of Network Devices
IP Devices - IP Phones should link ConnectableCIs instead of Network Devices
Feb 17, 2017
abstract class IPDevices back as a direct child of abstract class ConnectableCI
added class lnkConnectableCIToConnectableCI. This uses the table lnkConnectableCIToNetworkDevice for backward compatibility without any additional actions during install/upgrade (for now)
redefined abstract class ConnectableCI to show linked ConnectableCIs instead of linked NetworkDevices
What do these changes mean?
datamodel makes sense. IP Phone is NOT a datacenter device.
IP Phone can be linked to a network device (switch) and end user device (PC, printer...)
end user device (PC, printer) will show the linked IP Phone
impacts/depends on works from POV of connectable CI (pc, printer) and from the actual IPDevice (IP Phone, IP Device)
no changes to class NetworkDevice
no need to change anything about other network devices
I just spotted something which is not accurate in my datamodel.
IP Devices - IP Phones should link ConnectableCIs instead of Network Devices.
Somehow this got mixed up. Right now, you can link the IP Phone to a switch, but you can't link the IP Phone to a PC (if IP phone is actually a small switch as well, which is often the case).
The problem is: IP Devices are not necessarily 'datacenter' devices. An IP Phone is both a network device and an end user device as well. I'm also not entirely happy with Network Device being subclassed as a DataCenter device.
This leads to multiple options, both with their ups and downs.
Option 1
We could provide an additional class which mostly imitates lnkconnectablecitonetworkdevice. A new class (and database table) would be needed. We could either make it quite limiting ( lnkconnectablecitoipdevice ) or generic ( lnkconnectablecitoconnectableci ).
Upside: not redefining any other original classes.
Major downside: if you want the link to appear on for example a PC's or other connectable CI's tabs, every one of those classes (or a parent class) needs a redefinition or additional tab.
Option 2
An alternative would be to make our abstract IPDevice class be a child of Network Device. Again, this has undesired effects, since you'd inherit rack options etc. Also, it does not make sense to have IP Camera, IP Phone listed as DataCenter device.
Upside: our IP Devices would be visible on the "Network Devices" tab of for instance a PC.
Major downside: a lot would need to be hidden, which is possible though, especially since I made IPDevice an abstract class with is used by IP Device (generic), IP Camera and IP Phone.
Option 3
Redefining the Network Device, so it's not part of DataCenter class. Question: create a subclass for network switches, to allow for rack options etc? When talking about switches, this might be very useful. When talking about wifi access points, you can have them everywhere in the building, which again questions the definition of 'what is a DataCenter device'.
Upside: actually makes most sense of all.
Major downside: safe for iTop's original IP Phone which never made sense to me (or many others it seems), I'm not in favor of redefining entire classes to change their position in the data model. When done, it's likely to cause quite some head aches to convert everything properly, since I'm sure most of us have used this a lot already.
Other options may be possible as well.
So it's mainly a discussion about the place of DataCenter Device vs Network Device, or other options to consider so you can link all kinds of connectable CIs to IP devices.
IMHO, Option 2 may be the cleanest approach, since our IPDevice class was already based on the Network Device class.
The text was updated successfully, but these errors were encountered: