Hallo Nico, ich kannte diese Seite noch gar nicht, danke fuer den Hinweis! i-doit ist sehr anpassungsfaehig, d.h. Du kannst Dir Deine Umgebung so konfigurieren, wie Du es gerne haettest. Von daher ist es egal, ob Du einen Kunden mit einem Standort hast, oder eventuell auch Kunden mit mehreren Standorten, das laesst sich alles ziemlich leicht in i-doit abbilden. Du koenntest fuer Deine Umgebung z.B. die Kunden als Organisationen anlegen (mit dem Standort Root-Lokation), allerdings musst Du diese zuvor als Standort konfigurieren (Objekttyp-Konfiguration > Standort ja).  Anschliessend legst Du den/die Standort(e) fuer die einzelnen Kunden an, z.B. als Stadt oder einzelne Gebaeude und weist diesen den zuvor angelegten Kunden als Standort zu. Danach muessen nur noch alle Objekte unterhalb der Standorte angelegt werden und diesen entsprechend zugewiesen werden - damit waere die Abbildung Deiner verschiedenen Kundennetze abgeschlossen. Wie legt man einen Standort an? Zum besseren Verstaendnis beziehe ich mich hier auf die Demo (demo.i-doit.com, Login admin:admin): Den Reiter "Kontakte" auswaehlen, hier sind links bereits einige Objekttypen konfiguriert. Da es den Objekttyp "Organisation" bereits gibt, pruefen wir nur, ob dieser als Standort verwendet werden kann. Dafuer muss man lediglich links auf das "Kontakte" ueber den Objekttypen klicken, um so zur Objekttyp-Konfiguration zu gelangen. In der Uebersicht (http://demo.i-doit.com/?call=object_list&objGroupID=1000&viewMode=1003) sieht man, dass bei Organisation Standort auf nein steht. Diese Einstellung also auf ja aendern. Dabei am besten auch direkt die Kategorie Standort fuer diesen Objekttyp auswaehlen. Anschliessend ein neues Objekt vom Typ Organisation anlegen (hier: Kunde1) und als Standort Root-Lokation auswaehlen (klappt in der Demo nicht, daher nehme ich hier Düsseldorf als Standort). Wenn man jetzt auf die Standortsicht geht, sieht man bereits, dass es verschiedene Staedte gibt und dass Kunde1 in Duesseldorf sitzt. Es ist moeglich, entweder erst die Standorte (Staedte) aufzufuehren (wie in der Demo) und die Kunden entsprechend darunter zu verteilen, oder die Kunden anzulegen und darunter den/die Standort(e) einzutragen. Ich wuerde zweiteres bevorzugen, dann waere die Trennung auf Kundenebene bereits realisiert. Hoffentlich ist das nich noch verwirrender als bereits die Knowledge Base und das Handbuch Falls noch Fragen sind meld Dich einfach (PM). Gruss, jkondek

hallo jkondek, du hast vollkommen recht. ein link in das verzeichnis html und alles läuft ;O) thx 4 help hoffi

Hi, das Fehlverhalten im Rechtesystem habe ich nachstellen können und als Bug bei der Entwicklung gemeldet. Lieben Gruß

Servus, den virtual Host hast Du ja schon in der 000-default.conf drin, wozu nochmal bei i-doit.conf? Dort stehen doch einfach nur generelle Angaben drin, die dann i-doit in den versch. Hosts bereitstellen würden (sofern es mehrere gäbe, bspw. nochmal für SSL/443). Wenn Dein DocumentRoot im Server / 1.vhost /var/www ist, müßtest Du für i-doit unter /var/www/i-doit/ gar nix weiter eintragen. Anonsten reicht in der i-doit.conf meiner Meinung nach: Alias /i-doit/ "/var/www/i-doit/" <directory var="" www="" i-doit="">Options None   AllowOverride All   Order allow,deny   allow from all</directory> Der Directory-Block ist der Datei INSTALL der i-doit Installation entnommen, wo im Prinzip alles drin steht…. EDIT: Der Fehler wenn man so will ist einfach, in der 000-default.conf das DocumentRoot auf /opt/otrs/bin/cgi-bin zu setzen. Das gehört auf /var/www gesetzt! Die OTRS spezifischen Einstellungen macht man in der otrs.conf und die für i-doit in der i-doit.conf.

Servus zusammen, richtig, Mandanten werden in der OPEN Version nicht unterstützt. Ebenso wenig wie andere Sprachen (den DE-Support haben wir dann selbst zu Ende übersetzt für den internen Gebrauch). Das war selbst zu Zeiten von 0.9.x so. Damals gab es im Wiki - oder so, jedenfalls eine Subdomain unter i-doit.org, eine Anleitung, zusätzliche Mandanten händisch anzulegen. Dies funktioniert auch heute noch so! (ob nun die alte Anleitung 1zu1 paßt, keine Ahnung, sie ist mittlerweile verschwunden). Die Update-Funktion aus i-doit OPEN heraus (Systemeinstellungen -> System-Werkzeuge -> i-doit Update) funktioniert eh nicht, auch für die normale Installation, ohne Anpassungen oder händische Eingriffe. Das beginnt bereits dabei, dass der Check auf neue Updates nicht funktionieren kann. Die dazu geprüft XML-Datei unter der URL http://www.i-doit.org/updates.xml ist gar nicht vorhanden. Wohl aber die der PRO unter http://www.i-doit.com/updates.xml - da hat wohl jemand nur .com durch .org ersetzt Selbst wenn man dann auf die github-Seite geht und eine URL eingibt, z.B. eben die https://github.com/i-doit/i-doit/releases/download/v1.4.8/idoit-open-1.4.8-update.zip wird auch hier kein Download gestartet. Denn innerhalb der Update-Routine wird die eingegebene URL nochmals darauf geprüft, ob von i-doit.com bzw i-doit.de oder dev.synectics.de heruntergeladen wird und die Version auf 0.9.x lautet. Die Regex hierzu ist (in update.inc.php, Zeile 356): /^http[s]?\:\/\/(.*?[\.]?i-doit\.(com|de)|dev\.synetics\.de)\/.*?idoit.*?[\-\.0-9]+-update\.zip$ Irgendwie verreckt die Routine dann auch klanglos ohne Meldung (rein von Code sollte das nicht so sein). Man muß also das Update-ZIP herunterladen (direkt in das "Root" der i-doit Installation!) und dann entpacken, so dass dann unter ./updates/version das entsprechende Verzeichnis z.B. v1.4.8 liegt. Danach wird in Schritt 2 der Routine dieses auch erkannt und man kann dann normal fortfahren und die idoit_system Datenbank sowie die einzelnen Mandanten / Tenants (also auch händisch angelegte!) updaten. Haben wir selbst schon zweimal gemacht, geht wunderbar. Nachfolgendes bitte ich nicht als "bösgemeinte Kritik" zu verstehen, sondern es ist einfach mein persönlicher Eindruck (Meinung). Die Entwickler machen sicherlich ansonsten einen guten Job und haben vielleicht auch anderes zu tun. Irgendwie denke ich aber, dass da mit der heißen Nadel aus der PRO eine OPEN gebastelt wurde / wird, ohne viel Liebe in bestimmte Details zu stecken. Unschön finde ich zudem die "Verkrüppelung" mancher Funktionen (im Vergleich zu 0.9.x), damit diese dann rein PRO sind. @DJNova: Siehe Dein Thread / Frage bzgl. Sprache Deutsch ... [/s]

Hahahahaha Oft ist ja ganichts kaputt, man ist nur einfach zu blöde! Großartig, vielen Dank!

Hallo HofMar, vielen Dank für die Hinweise. Nach dem Aktualisieren auf die neue XAMPP Version stand in der phpinfo des PHP-Admin schon der richtige Pfad für die geladene Datei drin C:\XAMPP\php\php.ini. Allerdings könnte ich mir vorstellen, dass bei meiner Installation etwas nicht gepasst haben könnte. Ich habe dann unter htdocs ein 2. Verzeichnis (idoit2015) angelegt und hier ein frisches Setup aufgerufen. Gleich zu beginn beim pre-flight-check wurden dann die richtigen Werte ausgelesen (grüne Häkchen). Gruß Andreas [image: 1198_php_loaded_file.jpg]

Hallo Stefan, ich habe mir die Service Filter ein bisschen genauer angeschaut und konnte das von Dir beschriebene Verhalten nicht feststellen, dass alle "nicht anzuzeigenden Objekte" ausgegraut dargestellt werden, bei mir wurden die Objekte dargestellt, die im Filter zugelassen waren. Hast Du Dir einen eigenen Filter gebaut, oder einen vorhandenen genutzt? Kannst Du das Verhalten auf der Demo (demo.i-doit.com) nachstellen, bzw. Screenshots erstellen, damit wir das entsprechend ausprobieren koennen? Die umgekehrte Variante der Parameter/Bedingungen waere schon praktischer, oder zumindest eine Moeglichkeit zu entscheiden, ob die gewaehlten Parameter einbezogen oder nicht einbezogen werden sollen. Gruss, jkondek

hi, ich weiß nicht. Da das Handbuch nur erklärt, was die Optionen bedeutet, aber nicht erklären wie sie genutzt werden, würde ich das als sehr sinnvolle Stütze annehmen. Es ist ja wie bei einem Windows Server: auch dort gibt es für die wichtigsten Szenarien eine Gruppe (zumindest damals, als ich noch Windows 2000 administrieren durfte ..) Da würde nichts dagegen sprechen. In die Gleiche Kerbe würde ich auch schlagen, wenn es zum Beispiel eine Rolle "Buchhaltung" geben würde, bei der alles ausgeblendet wird, bis auf eben für die Buchhaltung notwendigen Informationen. Da frage ich mich eh, ob das jeder Benutzer für sich konfigurieren muss, oder ob ich als Admin das global vorkauen kann. Dafür muss ich nochmal die Suche beanspruchen cu denny

So jetzt antworte ich mir mal selbst, da ich den Punkt gefunden habe. Das Problem ist die "Sichtweise". Ich wollte das aus Sicht des virtuellen Switch (bzw. des virtuellen Host) machen. Das geht aber nicht (oder ich hab's noch nicht gefunden). Aber aus der Sicht der virtuellen Maschine geht es sehr wohl. Dort kann man unter "Virtual Machine" auch "Virtual devices" anlegen. Und genau da verbirgt sich auch der Punkt, wo man auswählen kann, wie das virtuelle Netzwerk konfiguriert ist. Also Bridged, Host-Only bzw. NAT oder eben den vSwitch (so dieser zuvor auf dem virtuellen Host aktiviert wurde). Ganz schön clever und eigentlich ganz einfach, wenn man weiß wie … Meine Frage ist damit also beantwortet. Gruß Martin

Hallo jkondek, Vielen Dank!!!!! Genau das habe ich gesucht!!!! Gruß, Yulia

Hello Leo, das mit dem "Kompatibilitätsmodus" war der entscheidende Hinweis. Im Internet Explorer war unter den "Einstellungen der Kompatibilitätsansicht" das Häkchen bei "Intranetsites in der Kompatibilitätsansicht anzeigen" gesetzt. Nachdem ich diese entfernt habe, läuft i-doit auch in der Zone "Intranet". Danke für diesen Tip! Gruß Martin

Hallo The.Man, das ist auch etwas, was ich am Abfrage-Editor bemaengel. Es gibt keine Moeglichkeit Summen zu bilden, zu sortieren, … Aber da ich meist eh den SQL-Editor nutze, ist das fuer mich kein Problem. Gruss, jkondek

Hallo, @dkirsten: ist schon absehbar in welchem Monat die 1.5er open released wird? Grüße

Ich glaube bereits einen Schritt weiter gekommen zu sein. in der NGINX Konfiguration stand folgendes: server {     server_name  otrs.betago.com;     listen otrs.betago.com:80;     access_log  /var/log/nginx/otrs_access.log;     # These 2 lines were necessary to prevent buffer problems in OTRS     fastcgi_buffers 8 16k;     fastcgi_buffer_size 32k;     fastcgi_read_timeout 300;     # Enter your htdocs path here, e.g. /opt/otrs/var/httpd/htdocs     root /opt/otrs/var/httpd/htdocs;     # Do not log favicon access     location = /favicon.ico {         access_log    off;         log_not_found  off;     }     location ^~ /otrs-web/ {         alias /opt/otrs/var/httpd/htdocs/;     }     location ~ ^/otrs/(.*\.pl)(/.*)?$ {         gzip off;         # Enter your fcgiwrap socket here         fastcgi_pass  unix:/var/run/fcgiwrap.socket;         fastcgi_index index.pl;         # Enter your OTRS cgi-bin path, e.g. <your_otrs_path>/bin/cgi-bin         fastcgi_param  SCRIPT_FILENAME /opt/otrs/bin/cgi-bin/$1;         include fastcgi_params;     } }</your_otrs_path> Ich habe jedoch auch folgende Konfiguration ergoogeln können: server {     server_name  otrs.betago.com;     listen otrs.betago.com:80;     access_log  /var/log/nginx/otrs_access.log;     # These 2 lines were necessary to prevent buffer problems in OTRS     fastcgi_buffers 8 16k;     fastcgi_buffer_size 32k;     fastcgi_read_timeout 300;     # Enter your htdocs path here, e.g. /opt/otrs/var/httpd/htdocs     root /opt/otrs/var/httpd/htdocs;     # Do not log favicon access     location = /favicon.ico {         access_log    off;         log_not_found  off;     }     location ^~ /otrs-web/ {         alias /opt/otrs/var/httpd/htdocs/;     }   location ~ ^/otrs/(.*\.pl)(/.*)?$ {     gzip off; fastcgi_pass unix:/var/run/fcgiwrap.socket; fastcgi_index index.pl; fastcgi_param SCRIPT_FILENAME  /opt/otrs/bin/fcgi-bin/$1; fastcgi_param QUERY_STRING      $query_string; fastcgi_param REQUEST_METHOD    $request_method; fastcgi_param CONTENT_TYPE      $content_type; fastcgi_param CONTENT_LENGTH    $content_length; fastcgi_param GATEWAY_INTERFACE CGI/1.1; fastcgi_param SERVER_SOFTWARE  nginx; fastcgi_param SCRIPT_NAME      $fastcgi_script_name; fastcgi_param REQUEST_URI      $request_uri; fastcgi_param DOCUMENT_URI      $document_uri; fastcgi_param DOCUMENT_ROOT    $document_root; fastcgi_param SERVER_PROTOCOL  $server_protocol; fastcgi_param REMOTE_ADDR      $remote_addr; fastcgi_param REMOTE_PORT      $remote_port; fastcgi_param SERVER_ADDR      $server_addr; fastcgi_param SERVER_PORT      $server_port; fastcgi_param SERVER_NAME      $server_name; } } Mit der zweiten Version kommt die Fehlermeldung Bad Gateway nicht mehr, aber dafür schon folgende Fehlermeldung: General error: SOAP call failed: looks like we got no XML document–-Please check your configuration settings, especially credentials and protocol (e. g. http) in service url. Ich suche weiter ;c)

Hi, danke, passt! Bis denn Thomas Wallutis

Update auf 1.4.9?