Posts made by freddy

Der Fehler besteht auch in Version 1.4.4 weiterhin.

Nach dem Update auf idoit Version 1.4(.3) ist bei uns an diversen Stellen (z.B. in der Level 3 Net Listen Ansicht) folgender Fehler aufgetreten:
array_unshift() expects parameter 1 to be array, null given (…/src/classes/helper/isys_helper_ip.class.php:846)

Das Problem ist auf einen fehlerhaften String Compare zurückzuführen der bei bestimmten IPv6 IPs das Problem auslöst.

Folgender Patch löst das Problem:

--- a/src/classes/helper/isys_helper_ip.class.php
+++ b/src/classes/helper/isys_helper_ip.class.php
@@ -795,7 +795,7 @@ class isys_helper_ip
                                                $l_address_arr[$l_key] = '0';
                                        }

-                                       if ($l_part == '0' || $l_part == '0000')
+                                       if ($l_part === '0' || $l_part === '0000')
                                        {
                                                $l_all_null[] = $l_key;
                                        }

Hallo,

wir hatten das selbe Problem.
Bei 1.3 wurden viele ehemalige config.inc.php optionen in die Datenbank verlagert.

Die ehemalige $g_connector_suffix_schema Variable wurde zum cmdb.connector.suffix-schema key. Beim updaten/konvertieren geht dabei aber wohl etwas schief.

Zum reparieren folgendes SQL Querie ausführen:

UPDATE idoit_system.isys_settings SET isys_settings__value = '["##INPUT## - OUT","- ##INPUT##","(*) ##INPUT##"]' WHERE isys_settings__key = "cmdb.connector.suffix-schema";

Wir haben für diesen Zweck einen neue Kategorie angelegt "Enclosure Accessoires" die auch eine Lokation sein kann.
Dort legen wir Sachen wie z.B. Kabelführungen, 19" Schubladen und eben auch Geräteböden an. Die können dann ganz normal im Rack Positioniert werden. Andere Geräte, etc. lassen sich dann z.B. der Schublade oder dem Geräteboden unterordnen.

Wir haben das selbe Problem bei uns in einem Rechenzentrum mit den beschriebenen Top of the Rack Switchen und zusätzlich noch bei der Etagenverkabelung wo mehrere physikalische Switche in verschiedenen Racks/Höheneinheiten mittels Stacking Modulen verbunden sind, es aber auch nur eine logische Verwaltung gibt.

Wir haben uns schließlich dazu entschieden jeden physikalischen Switch/Linecard als "Switch" Objekt anzulegen. Das hat den Vorteil das man den Standort, Inventarnummer, Seriennummer, Anschaffungsdatum, etc. korrekt eintragen kann. Die Ports des jeweiligen Switches benennen wir allerdings nach dem logischen/virtuellen Switch Interface Namen. Zusätzlich gibt es dann für jeden Switch-Verband ein Switch-Cluster (Objekttyp: Cluster), bei welchem die Switche entsprechend Mitglieder sind. Management IP, etc. sind dann dem Cluster-Switch zugeordnet.

Unsere Wunsch-Lösung ist das nicht, aber es funktioniert ganz gut.

Siehe auch folgende Threads:
http://forum.i-doit.org/index.php/topic,362.0.html
http://forum.i-doit.org/index.php/topic,2329.html

Anbei ein Patch der dafür sorgt das die Subnetze in der Supernet Ansicht überhaupt sortiert werden.

sort-supernet-subnets.patch.txt

Patch Post 2 (Forum limitiert maximale Anzahl von Anhängen)

cablerun-treeview-no-duplicates.patch.txt
cablerun-directly-connected-view.patch.txt

Patch Post 1 (Forum limitiert maximale Anzahl von Anhängen).

swap-cablerun-naming-right.patch.txt
swap-cablerun-naming-left.patch.txt
maintable-allow-copy.patch.txt
cablerun-sort-by-title.patch.txt

Hallo,

uns haben bei der Ansicht für die Verkabelung einige Sachen gestört die wir verbessert/hinzugefügt haben:

Die Tabellen lassen sich nicht ohne weiteres kopieren: "maintable-allow-copy.patch.txt" entfernt die verantwortlichen CSS Attribute.

Die Sortierung erfolgt ausschließlich nach den Typ: "cablerun-sort-by-title.patch.txt" sortiert zusätzlich noch nach dem Connector Namen.

Bisher wurden die einzelnen Schritte in der im Format "$AnschlussName ($ObjectName)" also z.B. "GigabitInterface/3 (Switch 17)"
angezeigt. "swap-cablerun-naming-left.patch.txt" + "swap-cablerun-naming-right.patch.txt" drehen das um – "Switch 17 (GigabitInterface/3)". Zuerst das Gerät, dann der Port ist nach unserem empfinden logischer/einfacher zu lesen.

In der TreeView wurden für Outputs mit gemeinsamen Inputs (z.B. bei einer PDU) jeweils ein eigener Input angelegt. "cablerun-treeview-no-duplicates.patch.txt" korrigiert das. Beispiel: Siehe tree-view-before.png und tree-view-after.png

Zuletzt hat uns eine Ansicht komplett gefehlt. Wir sind relativ häufig in der Situation das wir entsprechende Anweisungen für die Verkabelung von neuen Geräten an dritte (z.B. Remote Hands Personal) weitergeben müssen. Die bisherigen Ansichten enthalten immer den gesamten Pfad was in vielen Fällen zusätzliche Informationen enthält, welche gar nicht benötigt werden und nur zur allgemeinen Verwirrung beitragen. In der neuen "Directly Connected" Ansicht (cablerun-directly-connected-view.patch.txt) wird nur der jeweilige nächste Anschluss angezeigt.
directly-connected.png ist ein Beispiel für einen Switch welcher größtenteils an ein Patchpanel angeschlossen ist. Für den Anschluss des Switches ist die weitere Verkabelung der Patchpanel oder auch die Verkabelung der PDU bis zur Einspeisung nicht relevant.
Ein weiterer Vorteil der Ansicht ist das zusätzliche (im Browser unsichtbare) Zeichen enthalten sind, welche beim Kopieren der Tabelle als reiner Text (Kein HTML)  in einer gut lesbaren ASCII Liste (it fixed width font) resultiert (getestet mit Chrome und Firefox).
Beispiel:

Connection               	Connected to
Power                 -> 	cy-pdu1 (Outlet 22)
Console               -> 	cy-patch2 (01 - OUT)
GigabitEthernet1/0/01 -> 	cy-patch1 (01)
...

Die Patches basieren auf Version 1.0. Es würde mich freuen wenn die Änderungen als positiv wahrgenommen werden und in die nächste Version einfließen würden um das Nachpatchen bei Updates zu reduzieren.

Da hätte ich noch einige Verbesserungsvorschläge:

• Subnet liste nach TypPrefix sortieren
• Eingerückte (Auf-/zuklappbare) Anzeige von Subnetzen welche Teil eines anderen Super/Layer3-Nets sind
• Option um freie Subnetze anzuzeigen

Beispiel:

• 0.0.0.0/0 (Global IPv4)

  • 100.200.0.0/16 (RIPE allocation)

    • 100.200.0.0/19 (infrastructure)

      • 100.200.0.0/24 (servers)

      • 100.200.1.0/24 (free)

      • 100.200.2.0/23 (free)

      • 100.200.4.0/22 (free)

      • 100.200.8.0/21 (free)

      • 100.200.16.0/20 (free)

    • 100.200.32.0/19 (test)

    • 100.200.64.0/18 (free)

    • 100.200.128.0/17 (customer pool)

@creiss:

da sind wir momentan dran. In der nächsten Version wird es zudem Subnetting geben.

Bezieht sich "nächste Version" auf 1.0 oder 1.1?

Anbei der Patch für version 1.0

object-link-patch-1.0.diff.txt

Ich kann das Problem sehr gut nachvollziehen. Diese Usability Limitierung hat uns ebenfalls sehr gestört und wir haben das schon früh bei uns reingepatcht.
Anbei der Patch dafür (0.9.9 Version). Ist nicht besonders schön, aber erfüllt seinen Zweck. Der Patch verschiebt den Javascript Aufruf von dem href Attribut in das onclick Attribut und versieht den href Link mit einem richtigen Link so das man Objekte aus den Objekt Listen in einem neuen Fenster/Tab öffnen lassen.

Eventuell hat es eine Auswirkung auf den "Up" Link, da muss man bei uns zweimal draufdrücken. Das kann aber auch an was anderem liegen.
Es werden ebenfalls nur Links aus Objekt Listen angepasst, Links in der Object View/Tree View z.B. werden nicht angepasst (Das hat uns noch nicht genug gestört).

Ich würde es auch begrüßen wenn das i-doit Team sich mal der AJAX Navigation annehmen könnte.
Unter Verwendung des Hash Parameters in der URL oder sogar der History API könnte die usability deutlich gesteigert werden
Siehe auch:
http://ajaxpatterns.org/Unique_URLs
https://developer.mozilla.org/en-US/docs/DOM/Manipulating_the_browser_history

fix-object-link.diff.txt

Wir haben das selbe Problem und es mit zwei custom Container Objekten (Rohr + Kabelbündel).
Micropipes sind entsprechend Rohre im einem Rohr.
Das micro Rohr enthält wiederum Kabelbündel, welche die eigentlichen Fasern enthalten.

Wir haben auch das Problem bei neuen Mitarbeitern in Version 0.9.9-9.

Folgender Patch löst das Problem bei unserem Setup (LDAP auth):

--- a/src/classes/components/isys_component_dao_user.class.php
+++ b/src/classes/components/isys_component_dao_user.class.php
@@ -54,7 +54,7 @@ class isys_component_dao_user extends isys_component_dao
                                if ($l_res && ($l_res->num_rows() == 0))
                                {
                                        // OK, there is no entry. Create one.
-                                       $l_q = "INSERT INTO isys_user_setting VALUES (DEFAULT, " .$this->convert_sql_id($l_piID) . ", NULL)";
+                                       $l_q = "INSERT INTO isys_user_setting VALUES (DEFAULT, " .$this->convert_sql_id($l_piID) . ")";

                                        if ($this->update($l_q))
                                        {

massdit in Kombination mit quick save funktioniert nicht:
Folgender button wird erzeugt:

Bei onclick fehlt ein Semikolon

Fix:

--- a/src/themes/default/smarty/templates/modules/multiedit/main.tpl
+++ b/src/themes/default/smarty/templates/modules/multiedit/main.tpl
@@ -50,7 +50,7 @@

-               [{isys type="f_button" name="saveList" p_onClick="Multiedit.save()" p_strValue="LC__UNIVERSAL__BUTTON_SAVE"}]
+               [{isys type="f_button" name="saveList" p_onClick="Multiedit.save();" p_strValue="LC__UNIVERSAL__BUTTON_SAVE"}]
                ![](images/ajax-loading-big.gif)

Habe noch ein wenig probiert, liegt wohl an der Reinfolge wie die Anschlüsse angelegt werden (bzw. exportiert/importiert werden).
Anbei ein Beispiel export.
out1 wurde vor in1 erstellt und wird unvollständig importiert, out2 wurde nach in2 erstellt und wird richtig importiert.

PS: Euer Forum erlaub nicht das hochladen von xml Dateien.

idoit-export-20120522121127.xml.txt

Da das demo system wohl täglich resettet wird hier zwei Screenshots.
man beachte das Netz Feld

Sowohl als auch (dürfte wohl das selbe Feld sein)

Beispiel in eurem Demo System:
http://demo.i-doit.com/index.php?viewMode=1100&objTypeID=31&mNavID=2&tvMode=1006&tvType=1&editMode=0&objID=8567&catsID=22&

In Version 0.9.9-9 gehen nach einem ersten Test zwar wohl keine Anschlüsse mehr verloren aber die Zuordnung von Ausgängen zu Eingängen (Corresponding intput) geht beim duplizieren noch verloren.