Hallo,
da fehlt wohl noch die Zuweisung der Kategorie "Verkabelung (Ordner)" zum Objekttyp "Patchdosen".
Ciao
Sven
Hallo,
da fehlt wohl noch die Zuweisung der Kategorie "Verkabelung (Ordner)" zum Objekttyp "Patchdosen".
Ciao
Sven
Hallo Thomas,
wenn man das Update über das i-doit Webfrontend macht, wird das jeweilige Updatepaket in diese Verzeichnisse mit der entsprechenden Versionsnummer entpackt und dann von dort in den i-doit-Ordner kopiert. Bei einem manuellen Update müsstest Du das Updatepaket im i-doit-Ordner entpacken, damit Dir diese Version dann im GUI als Update angeboten wird. Nach dem Update kann das Verzeichnis weg, es sei denn, man würde das gleiche Update noch einmal ausführen wollen.
In der Knowledgebase steht bestimmt was zum manuellen Update, das solltest Du mal lesen.
Nachtrag: Nö, speziell diese Verzeichnisse werden da nicht erwähnt, da wird nur beschrieben, dass man das Updatepaket entpacken soll, dabei entstehen diese Verzeichnisse aber:
https://kb.i-doit.com/display/de/Update+einspielen
Ciao
Sven
Hallo,
also in der PRO-Version geht das in unter Verwaltung - CMDB-Einstellungen - Quick Configuration Wizard.
Ob das in der Open-Version auch so ist, kann ich allerdings nicht sagen.
Ciao
Sven
Hallo,
die Rechte sind auch korrekt gesetzt für den Nutzer, der im Controller-Aufruf angegeben ist?
Siehe Attachment.
Ciao
Sven
Hallo,
wir hatten den Fehler auch schon mal und haben nach einiger Zeit und nach einer Remotesession, wo wir unsere diversen VIVA-Probleme vorgeführt haben und in der DB gewühlt wurde, einen Patch bekommen, der das und noch einige Fehler beheben sollte, speziell dieser Fehler wurde aber damit nicht behoben.
Für das Problem haben wir später einen Handler für den Controller erhalten, der die DB korrigiert hat, das lag tatsächlich an fehlerhaften Daten in der DB, wie auch immer die zustande kamen. Vielleicht war mal eine VIVA-Version fehlerhaft oder bei einem Modul-Update ist was schief gegangen, wir haben VIVA schon eine Weile im Einsatz.
Bitte beim Support auf Bugrequest #433 beziehen.
So, jetzt prüfe ich noch mal, ob inzwischen schon eine neue VIVA-Version erschienen ist, die das schon enthalten könnte …
... nö, im Supportbereich wird immer noch Version 1.5.1 angeboten, die wohl nur die Kompatibilität mit Version 1.9.x sicher stellt.
Es sind auch noch längst nicht alle Bugs behoben, die wir zu VIVA gemeldet haben bzw. in der Remotesession weiter gegeben haben.
Das war alles vor ca. 1 Monat, ich hoffe, die VIVA-Version mit den Korrekturen kommt bald. Aber so kurz vor der Anwenderkonferenz ...
HTH
Ciao
Sven
Hallo,
also entweder könnte das was mit den mysql-Treibern von PHP zu tun haben - mysqli bzw mysqlnd - oder mit dem Zugriff auf die DB über localhost bzw. 127.0.0.1, wo einmal wohl ein Socket verwendet wird bzw. eine TCP-Connection.
Wenn Du localhost verwenden solltest, dann versuche einfach mal 127.0.0.1.
Wir mussten seinerzeit mysqlnd nachinstallieren, damit das funktioniert, das war aber mit PHP 5.4. Ich kann auch nicht mehr wirklich sagen, ob das exakt dieser Fehler war.
Vielleicht bringt Dich das auf die richtige Spur.
Bei uns steht demnächst auch die Umstellung auf PHP 7 an. Insofern verfolge ich das mit Interesse.
Ciao
Sven
Ich möchte auch Bedarf für dieses Feature anmelden.
Ciao
Sven
Hallo,
um nicht nur zu kritisieren: Ich kann für mich sagen, dass die Zusammenarbeit mit dem Support wirklich gut ist und ich die Hilfsbereitschaft hier im Forum echt prima finde. Also auch ein Lob an Synetics, ihr habt ja auch ein tolles Produkt.
Ciao
Sven
…
Ich werde nie verstehen, warum eine Modifikation ohne Releaseanhebung (Iteration) ausgeliefert wird, sodass dies einwandfrei kommunizierbar und somit verteilbar wird.
Soetwas sollte nicht passieren, eine 1.9.1 wäre doch nicht verkehrt gewesen um diese im Update-Modul zu sichten ... auch wenn es 5min nach Release der 1.9 war.
...
Da kann ich ehrlich gesagt nur zustimmen. Das stiftet nur Verwirrung. Ich wurde beauftragt, auf 1.9v2 zu aktualisieren, angeboten wurde mir über das GUI nur 1.9 und danach nichts mehr. Hab ich jetzt v2 oder nicht? Hab ich, aber sehen kann man das nicht wirklich. Da war ich anfangs etwas verwirrt.
Ciao
Sven
Hallo,
wenn ich das richtig verstanden habe, ist das ein Bug in der ursprünglich erschienenen Version 1.9 der in 1.9v2 nicht mehr enthalten ist. Ich habe das Update erst vergangenen Freitag gemacht, da war dieser Bug schon behoben.
Leider steht das "v2" nicht im GUI. Im Update-Bereich wurde mir das auch nur als 1.9 angeboten.
Ciao
Sven
Hallo,
also hier funktioniert das Admin-Center nach unserem Update am Freitag.
Cache löschen am besten immer in der i-doit Verwaltung und im Browser.
Ciao
Sven
Noch ein Hinweis: In der DB idoit_data sind nicht alle Daten des Mandanten enthalten. Die Reports sind in idoit_system gespeichert. Was den Umzug eines Mandaten, wie von dkirsten oben beschrieben, etwas komplizierter macht.
Ich finde das ungünstig. Alle mandanteneigenen Daten sollten eigentlich in der DB des Mandanten sein. Lediglich die Metadaten zum Mandant, Lizenz, DB usw. würde ich in die System-DB speichern.
Aber vielleicht gibt es ja gute Gründe dafür, die mir nicht bekannt sind, das so zu machen.
Ciao
Sven
Hallo,
da fehlt nach dem ORDER BY der Feldname.
Ciao
Sven
Hello,
please post a short example of your import.csv.
bye
Sven
Hallo,
das ist etwas schwer zu beantworten, weil wir ja nicht wissen wie es in Deinem DBMS aussieht.
Gib mal Host und Database im mysql-Kommando mit an und teste das erstmal manuell und gib mal hier das Ergebnis bekannt.
Die DB idoit_data gibt es schon?
Und wurde denn überhaupt schon was aus dem sql-File importiert?
Ciao
Sven
Hallo Stefan,
wahrscheinlich liegst Du mit Deiner Vermutung richtig. Bei mir ist die ID 9 und SYSID_1280838787 der Nutzer "admin" (Person) und da Dein PC aus dem JDisc Import auch "admin" hieß, hast Du den wohl mit dem JDisc-Import teilweise oder ganz überschrieben und u. a. den Objekttyp auf "Client" geändert.
Ein Kollege hat mir von ähnlichen Problemen berichtet. Der hat sich auch den admin-User überschrieben.
Ciao
Sven
Hallo,
die Lösung findest Du in diesem Thread:
https://forum.i-doit.org/index.php/topic,4943.msg15140.html#msg15140
Ciao
Sven
Moin,
ich hoffe doch, dass das nicht geht. Und wenn doch, dann hoffe ich, dass das unsere i-doit-Nutzer nicht herausfinden. Dann machen demnächst solche Links die Runde.
Schreib doch mal, was Du damit vor hast, dann gibt es bestimmt jemanden hier, der Dir einen weniger problematischen Weg zeigen kann.
Automatisieren kann man bei einigen Sachen auch anders, wget mit POST-Daten übertragen geht m. E. auch. wget und curl können wahrscheinlich auch mit Session Cookies umgehen. Und der Controller von i-doit kann auch einiges …
Da muss man dann mal einfach mal sehen, was genau Du vor hast.
Ich gehe mal nicht davon aus, dass es Dir um die reine Bequemlichkeit geht, Dich nicht extra anmelden zu müssen.
Aber Passwörter in der Url würde ich wirklich nicht sehen wollen.
Ciao
Sven
Hallo,
falls Du das als SQL-Abfrage machen willst, ist hier des Feld-Glossar, da steht auch oben, wie Du das auf Deinem eigenen System aufrufen kannst:
https://kb.i-doit.com/display/de/Feld-Glossar+Version+1.8
Ob das aber in dem Fall überhaupt notwendig ist, kann ich nicht sagen, da ich bisher nur SQL-Abfragen gemacht habe.
Ich könnte mir aber vorstellen, dass das auch ohne SQL geht. Ich nehme mal an, dass der Objektstatus dafür verwendet wird.
Mal sehen, was andere schlaue Leute hier noch beisteuern.
Ciao
Sven