... | @@ -95,3 +95,17 @@ A subnet lists the DNs of the mapped VLANs. |
... | @@ -95,3 +95,17 @@ A subnet lists the DNs of the mapped VLANs. |
|
* Allows the user to configure the column and company display, to sort as he wants (to verify that it works in a tab but it should do it. A priori there will be no filter box)
|
|
* Allows the user to configure the column and company display, to sort as he wants (to verify that it works in a tab but it should do it. A priori there will be no filter box)
|
|
* The interfaces are defacto linked to the system: we delete it, they are deleted, we move it they are moved
|
|
* The interfaces are defacto linked to the system: we delete it, they are deleted, we move it they are moved
|
|
* The interface <> system link is directly modeled and does not require an LDAP field + an LDAP search, we can see directly in the dn / tree which is associated with whom.
|
|
* The interface <> system link is directly modeled and does not require an LDAP field + an LDAP search, we can see directly in the dn / tree which is associated with whom.
|
|
|
|
|
|
|
|
## Current breakage
|
|
|
|
|
|
|
|
This currently breaks:
|
|
|
|
* System creation for system types with mandatory IP
|
|
|
|
* System templates
|
|
|
|
* System import (OPSI import at least)
|
|
|
|
* Webservice access (not tested)
|
|
|
|
* Unicity checks on IPs and Macs (Pop-up shows but the interface object
|
|
|
|
already changed)
|
|
|
|
|
|
|
|
Also saving an interface modification and then canceling the system
|
|
|
|
edition will leave the LDAP data with inconsitent data, so we need to
|
|
|
|
somehow trigger system save upon interface save. |