OTRS umzug - Darstellungsprobleme HTML wird nicht korrekt dargestellt

[MAKUT]

Danke jojo dessen bin ich mir wohl bewusst. Bringt mich nur keinen schritt näher an eine Lösung.
Aber gut das du das nochmal erwähnt hast..

[jojo]

Hast Du die Config.pm wieder angepasst (DefaultCharset auf utf-8)?

[wurzel]

Hi,

Wenn ich nun auf die ZZZAuto Datei zugreifen und diese Bearbeiten will wird mir eine Warnung angezeigt das dort ungültige Zeichen existieren und das ich die Datei eventuell durch bearbeiten unbrauchbar mache.

Wenn es nur die ZZZAuto.pm ist, die kann man relativ einfach reparieren. In utf8 umkonvertieren und Fehlerhafte Zeichen ersetzen.

Sollte gehen.

Du hast ja erstmal nur Testmigriert richtig? Dann fang' doch nochmal an von vorne

viele Grüße
Flo

[MAKUT]

Soo,

ich habe jetzt die ZZZAuto konvertiert.

vorher:

Code: Select all

[root@OTRS Files]# file -i ZZZAuto.pm
ZZZAuto.pm: text/plain; charset=iso-8859-1

nachher:

Code: Select all

[root@OTRS Files]# file -i ZZZAutoutf8.pm
ZZZAutoutf8.pm: text/plain; charset=utf-8

Und das OTRS lässt sich nun auch wieder problemlos starten.
Die Umlaute in den alten Tickets sind jedoch noch immer giblerisch.

Ich gehe mal stark davon aus das die überhastete Aktion mit dem Zeichensatz die Quelle dieses Übels ist.


... wie der Flo schon anmerkte war das ganze sowieso erst mal nur ein Testupgrade um durch zu steigen
Ich werde als nächstes noch eins machen mit Fokus auf Zeitmanagement. Die Downtime muss klein gehalten werden wenn's ans Produktivupdate geht.


Noch einmal ein herzliches Dankeschön an alle die mir hier geholfen haben das Kind zu schaukeln!!!!

Hab in kurzer Zeit recht viel gelernt und ihr habt mich echt gut ausgehalten. Glückwunsch

[wurzel]

Hi,

cool. Weiterhin viel Erfolg!!

Flo

[MAKUT]

Hi Dideldi Ho Nachbarinos.


Der 2. Testlauf lief wie am Schnürchen. Folglich werden wir in 2 Wochen das Produktivupdate an gehen.

Dazu hätte ich noch 2 Fragen.


1. Ticket Counter

ich habe die Datei TicketCounter.log beim Migrieren immer fleißig mit gezogen.
Wenn ich nun aber im 5er OTRS ein ticket erstelle Ist das total außerhalb der Reihe was die Nummer angeht.
Sieht für mich aus wie eine Kombination aus Aktuellem Datum und einer Fortlaufenden Nummer, die aber nicht mal im entferntesten der im TicketCounter mitgenommenen Nummer ähnelt.

Muss ich da wohl im Frondend noch die passende Eigenschaft finden und ändern oder ist das mitnehmen des Counters von 3 nach 5 nicht so einfach möglich?


2. Optimierungen

Wenn wir das Ticketcenter laufen haben gibt es ja mit Sicherheit noch mehrere Schräubchen an denen es sich unter Umständen zu drehen lohnt.
Gibt es dafür zufällig ne FAQ oder einen Guide der die relevanten Optionen auf zeigt oder Empfehlungen gibt?


Danke schonmal im Vorraus.


Gruß

Alex

[wurzel]

Hi,


na also



Dein Ticket Counter ist in Core::Ticket eingestellt. Wenn Du die ZZZAuto.pm sauber mit migrierst sollte auch in der aktuellsten Version der Ticket Counter identisch sein.

Aktuellem Datum und einer Fortlaufenden Nummer, die aber nicht mal im entferntesten der im TicketCounter mitgenommenen Nummer ähnelt.

Datum + fortlaufende Nummer (oder Checksum) ist eine Mögliche Generierung

aus der aktuellen Sysconfig...

Code: Select all

Selects the ticket number generator module. "AutoIncrement" increments the ticket number, the SystemID and the counter are used with SystemID.counter format (e.g. 1010138, 1010139). With "Date" the ticket numbers will be generated by the current date, the SystemID and the counter. The format looks like Year.Month.Day.SystemID.counter (e.g. 200206231010138, 200206231010139). With "DateChecksum" the counter will be appended as checksum to the string of date and SystemID. The checksum will be rotated on a daily basis. The format looks like Year.Month.Day.SystemID.Counter.CheckSum (e.g. 2002070110101520, 2002070110101535). "Random" generates randomized ticket numbers in the format "SystemID.Random" (e.g. 100057866352, 103745394596). 

Der Ticket Counter (TicketCounterLog) mitzunehmen ist einfach copy. Nichts weiter zu beachten. File Rechte müssen halt passen.


zu Punkt zwei
ich kenne keine FAQ/Guides. Erfahrung (durch Testmigration) sammeln ist 'n guter Weg.
Und da uns Deine Konfiguration (und auch Arbeitsweise/Workflows/Prozesse/...) unbekannt sind
kann man auch schlecht Tipps geben. Nicht umsonst sind Review Workshops mit Beratern
gerne 2-3 Tage lang. Das ist "nicht mal so" einfach zu machen.

viele Grüße und viel Erfolg bei der Migration

Flo

[MAKUT]

HI,

Dein Ticket Counter ist in Core::Ticket eingestellt. Wenn Du die ZZZAuto.pm sauber mit migrierst sollte auch in der aktuellsten Version der Ticket Counter identisch sein.

Leider nein.

Habe jetzt noch ein 2. mal durch migriert und es bliebt dabei. Die Ticketnummern werden nicht fortgesetzt.
ZZZAuto wurde immer brav mit gezogen

Berechtigungen:

Code: Select all

drwxrwsr-x 3 otrs apache    43 24. Nov 09:53 log

Code: Select all

-rwxrw-rw- 1 otrs apache   13 24. Nov 10:48 TicketCounter.log

Außerdem habe ich jetzt wieder 1 altes und 1 neues Problem. : /

Alt: Die Tickets sehen wieder aus wie ganz zu beginn.

Berechtigungen:

Code: Select all

[root@OTRS article]# ls -l
insgesamt 0
drwxr-xr-x 14 root apache 114  1. Dez 2015  2015
drwxr-xr-x 13 root apache 105  1. Nov 00:00 2016

Da bin ich nun vollkommen ratlos.

habe die Besitzrechte mit

Code: Select all

chown -R otrs * 

auf alle Ordner und unterordner übertragen aber es bleibt dabei.


2. Ein ganz neuer Fehler...

Ich habe eine Testqueue eingerichtet um den Mailempfang zu testen.
Die Mails kommen an, werden aber scheinbar nicht korrekt verarbeitet.

Im Log steht

Code: Select all

Thu Nov 24 10:48:07 2016 	error 	OTRS-CGI-10 	POP3: Can't process mail, mail saved (/opt/otrs/var/spool/problem-email-46a0d22d5cca4d451c0d367fb89e7869, report it on http://bugs.otrs.org/)!
Thu Nov 24 10:48:06 2016 	error 	OTRS-CGI-10 	No StateID for 'new'!

und im ordner var/spool erscheinen die Mails als Problem Mail.

Was ist denn da nun passiert? Ich habe nichts anders gemacht.


MfG

Alex

[MAKUT]

Kommando zurück!

Berechtigungsproblem behoben.

Die Gruppe hat sich geändert also auch die nötigen Berechtigungen.

var/article steht hab ich jetzt auf 770 geändert

Nu gehts.


Bleibt nur das mit der State ID

[wurzel]

Hi,

was sagt

SELECT id,name,type_id,valid_id FROM ticket_state

Alles valid?

viele Grüße
Flo

[MAKUT]

Hi,

Code: Select all

MariaDB [otrs]> SELECT id,name,type_id,valid_id FROM ticket_state;
+----+-------------------------+---------+----------+
| id | name                    | type_id | valid_id |
+----+-------------------------+---------+----------+
|  1 | neu                     |       1 |        1 |
|  2 | erfolgreich geschlossen |       3 |        1 |
|  3 | geschlossen (erfolglos) |       3 |        1 |
|  4 | offen                   |       2 |        1 |
|  5 | entfernt                |       6 |        1 |
|  6 | pending reminder        |       4 |        1 |
|  7 | pending auto close+     |       5 |        1 |
|  8 | pending auto close-     |       5 |        1 |
|  9 | zusammengefasst         |       7 |        1 |
+----+-------------------------+---------+----------+

Das Berechtigungsproblem hab ich schon gelöst. chmod 770 passt.

[wurzel]

Hi,

Du hast keinen state new


Namen in der sysconfig anpassen oder states anpassen.

viele Grüße
Flo

[MAKUT]

Guten Morgen,

ich habe die Variablen für Ticket_state in der Sysconfig angepasst (übersetzt)


Nun wird mir der Error zwar nicht mehr angezeigt, die Mails laufen trotzdem noch in /var/spools/ als problem mails auf.

Habe in der SysConfig


Ticket::Frontend::AgentTicketProcess###StateType übersetzt

genauso wie auch

Ticket::Frontend::AgentTicketEmail###StateType

und

Ticket::Frontend::AgentTicketEmail###StateDefault


Wie kann das denn überhaupt sein, das in der DB die Stati übersetzt werden und im OTRS nicht?

[RStraub]

Oha, hast du die Statusnamen über die DB übersetzt?

[MAKUT]

Hi RStraub,

in der DB hab ich garnichts Manuell gemacht.

Wie sagt man so schön, ""das war schon so"!

Ich habe nur in der SysConfig was übersetzt vor 10 Min. hab aber alles auf geschrieben also einfach wieder rückgängig zu machen.

[MAKUT]

Nachtrag


Bei stöbnern in der Sysconfig ist mir aufgefallen das unter

Ticket::Frontend::AgentTicketEmail###StateDefault
Das Standardwert laut OTRS 'open' ist. Wenn ich jedoch auf 'diese Einstellung zurücksetzen' klicke steht in dem Feld 'entfernt' statt 'open'

Was mag denn da passiert sein?


EDIT: 'offen' lässt sich dort eintragen. Trage ich aber 'open' ein wird 'entfernt' daraus.
irgendwas ist da ganz gehörig durcheinander.

[RStraub]

Hey Makut,

ich glaube da sind deutliche Anpassungen am Framework vorgenommen worden. Im Standard steht der Wert nämlich auf open:
https://github.com/OTRS/otrs/blob/maste ... .xml#L3473

Auch sollten diese fix-englischen Begriffe überhaupt nicht übersetzt werden... das sieht sehr mysteriös aus.

[MAKUT]

Hi RStraub,

ja ich bin auch etwas verwirrt.
Ist ja nicht das erste mal das ich auf 5 hoch migriert habe und DAS hatte ich tatsächlich noch nie.

Ich habe sicher nichts am Framework gebastelt und ich bin auch der einzige hier der da Hand an legt.

[jojo]

das Problem sind die übersetzten Status in der DB! Die hat definitiv jemand nachträglich übersetzt.

[MAKUT]

Hi Jojo,

wenn es dafür kein Script in der Admin Console gibt kann ich das 100% ausschließen.

Wie bereits gesagt bin ich der einzige hier der am OTRS arbeitet. Es hat nicht mal jemand anderes Zugang zu der VM.

Und ich hab definitiv nichts übersetzt.
Das einzige was ich mit der DB gemacht habe waren Default charset der DB otrs auf utf8 gestellt und collation oder wie sich das schimpft auf utf8_general_ci
Ansonsten ist an der DB nichts gemacht worden.

Dann ist es wohl am einfachsten wenn ic h die ticket_state Tabelle wieder ins Englische übersetze damit die Attribute wieder passen oder?


Gruß

Alex

[jojo]

man kann die Status im Frontend übersetzen, das hast Du wohl gemacht.

[RStraub]

Laut der Antwort 4-5 Posts weiter oben (siehe SQL-Query) sind die Status in der DB und nicht im Frontend übersetzt.

[MAKUT]

Hi Jojo,

wenn du kommentierst dann mach dir doch bitte mal die Mühe mehr als nur den Letzten Beitrag zu lesen.

Wie ich sagte habe ich im Frontend erst dann übersetzt als die diskrepanz zur entsprechenden n DB Tabelle aufgefallen ist.

Vorher habe ich NICHTS übersetzt.
Ich habe das OTRS hoch gezogen und sämtliche einstellungen die das frontend/postmaster oder sonstiges das mit den Ticketstati zu tun hat unverändert gelassen.
Genau das selbe gilt für die DB ich bin da nicht dran gewesen.

[jojo]

Das Frontend (ich rede nicht von der Sysconfig) gibt natürlich die Inhalte der Datenbank wieder. Da die Datenbank von uns ausschließlich auf englisch für die Status geliefert wird, hat sie jemand im Frontend geändert.

Du musst nun entweder die Tabelle wieder auf den Ursprungszustand bringen (die Sysconfig dann auch wieder auf Defaults setzen) oder die Sysconfig dementsprechend korrekt anpassen.

Ich empfehle allerdings dringend hier kommerzielle Hilfe und/oder Schulung in Anspruch zu nehmen!

[MAKUT]

Hi,

also passte ja meine Annahme. Der einfachste weg ist die Tabelle wieder in den Ursprungszustand zu bringen.

Das werde ich dann mal tun. Und sollte es in die Hose gehen werd ich halt die VM wieder auf 4.0 zurücksetzen und den letzten schritt wiederholen.
Ist ja alles in der Testumgebung.

[MAKUT]

Kann mir jemand vielleicht mal diese Tabelle im Originalzustand posten als Referenz?
Das wäre dufte.


Gruß

Alex

[MAKUT]

@jojo

Ich habe mir auch bereits Angebote von entsprechenden Dienstleistern eingeholt.
Das was ich hier mache ist nichts anderes als learning by doing. Sollte das ganze nicht so laufen wie ich mir das vorstelle wird natürlich die Hilfe in Anspruch genommen.
Ich würde niemals an Produktivsystemen herum pfuschen wenn ich nicht sicher bin bei dem was ich tue.


Gruß

Alex

[jojo]

Anscheinend fragst Du nicht die richtigen Dienstleister... Bei uns als Hersteller warst Du noch nicht vorstellig...

Hier das Orginal SQL

Code: Select all

# ----------------------------------------------------------
#  insert into table ticket_state
# ----------------------------------------------------------
INSERT INTO ticket_state (id, name, comments, type_id, valid_id, create_by, create_time, change_by, change_time)
    VALUES
    (1, 'new', 'New ticket created by customer.', 1, 1, 1, current_timestamp, 1, current_timestamp);
# ----------------------------------------------------------
#  insert into table ticket_state
# ----------------------------------------------------------
INSERT INTO ticket_state (id, name, comments, type_id, valid_id, create_by, create_time, change_by, change_time)
    VALUES
    (2, 'closed successful', 'Ticket is closed successful.', 3, 1, 1, current_timestamp, 1, current_timestamp);
# ----------------------------------------------------------
#  insert into table ticket_state
# ----------------------------------------------------------
INSERT INTO ticket_state (id, name, comments, type_id, valid_id, create_by, create_time, change_by, change_time)
    VALUES
    (3, 'closed unsuccessful', 'Ticket is closed unsuccessful.', 3, 1, 1, current_timestamp, 1, current_timestamp);
# ----------------------------------------------------------
#  insert into table ticket_state
# ----------------------------------------------------------
INSERT INTO ticket_state (id, name, comments, type_id, valid_id, create_by, create_time, change_by, change_time)
    VALUES
    (4, 'open', 'Open tickets.', 2, 1, 1, current_timestamp, 1, current_timestamp);
# ----------------------------------------------------------
#  insert into table ticket_state
# ----------------------------------------------------------
INSERT INTO ticket_state (id, name, comments, type_id, valid_id, create_by, create_time, change_by, change_time)
    VALUES
    (5, 'removed', 'Customer removed ticket.', 6, 1, 1, current_timestamp, 1, current_timestamp);
# ----------------------------------------------------------
#  insert into table ticket_state
# ----------------------------------------------------------
INSERT INTO ticket_state (id, name, comments, type_id, valid_id, create_by, create_time, change_by, change_time)
    VALUES
    (6, 'pending reminder', 'Ticket is pending for agent reminder.', 4, 1, 1, current_timestamp, 1, current_timestamp);
# ----------------------------------------------------------
#  insert into table ticket_state
# ----------------------------------------------------------
INSERT INTO ticket_state (id, name, comments, type_id, valid_id, create_by, create_time, change_by, change_time)
    VALUES
    (7, 'pending auto close+', 'Ticket is pending for automatic close.', 5, 1, 1, current_timestamp, 1, current_timestamp);
# ----------------------------------------------------------
#  insert into table ticket_state
# ----------------------------------------------------------
INSERT INTO ticket_state (id, name, comments, type_id, valid_id, create_by, create_time, change_by, change_time)
    VALUES
    (8, 'pending auto close-', 'Ticket is pending for automatic close.', 5, 1, 1, current_timestamp, 1, current_timestamp);
# ----------------------------------------------------------
#  insert into table ticket_state
# ----------------------------------------------------------
INSERT INTO ticket_state (id, name, comments, type_id, valid_id, create_by, create_time, change_by, change_time)
    VALUES
    (9, 'merged', 'State for merged tickets.', 7, 1, 1, current_timestamp, 1, current_timestamp);
  

[MAKUT]

....danke

[RStraub]

Anscheinend fragst Du nicht die richtigen Dienstleister

Whohhoa, das is doch aber mal ne krasse Aussage...

[MAKUT]

Anscheinend fragst Du nicht die richtigen Dienstleister



Whohhoa, das is doch aber mal ne krasse Aussage...

Jap... schon klar..Niveau sieht nur von unten aus wie Arroganz....

[MAKUT]

Hallo zusammen.

Kurzes Update:

Datenbank in der OTRS 3.0 Version wieder auf Ursprungszustand zurück gesetzt und alles In Frontend und SySConfig angepasst.

Danach dann die Migration begonnen.

Migration läuft sauber durch.
Alle Funktionen arbeiten sauber. Dank euch!

Nun habe ich aber nochmal ne kleine Frage.

Sobald ich im Terminal den otrs.Daemon starte nimmt er seine Arbeit auf. Was mich jedoch stört ist, das im Terminal ständig die aktuell laufenden Arbeiten des dienstes ausgeworfen werden und das Terminal blockieren.

Unbenannt.PNG

Lässt sich das ganze in den Hintergrund bringen oder muss ich damit leben und nach aktivierung einfach eine neue Session starten?


Beste Grüße

Alex

[wurzel]

Hi,

müsste mit >> /dev/null gehen... schau mal in die crontab


viele Grüße
Florian

[MAKUT]

HI,

bissl lange nicht da gewesen hab schon gefunden. Gibt nen silent switch wenn man den daemon startet.

am 6.1. Is Migration des Produktivsystems. Ich gehe mal davon aus das alles rund läuft, werde aber nochmal laut geben.


Danke sehr


MfG

Alex

[MAKUT]

Grüß euch,

ich bin da gestern auf ein kleines Problem gestoßen das ich mir nicht so ganz erklären kann.


Unsere Automatische Antwort bei Maileingang ist folgende:

Sehr geehrte/r <OTRS_CUSTOMER_REALNAME> ,

vielen Dank für Ihre Nachricht.

Dies ist eine automatisch erstellte Eingangsbestätigung Ihrer E-Mail, die bei uns unter folgender Nummer bearbeitet wird: T#<OTRS_TICKET_TicketNumber>

Eine Antwort auf Ihre Nachricht erhalten Sie in der Regel spätestens am nächsten Werktag. Bitte haben Sie Verständnis, wenn am Wochenende keine E-Mails beantwortet werden können.

Das Tag <OTRS_CUSTOMER_REALNAME> funktioniert jedoch nicht.

Es wird immer die Systemadresse der empfänger Queue übergeben in diesem fall "TestqueueAPI@xyz.de".

Laut Referenz ist das aber das richtige Tag.

Der hier scheint das selbe Problem zu haben

viewtopic.php?f=62&t=33365&p=135595&hil ... 52#p135595

Kannst du mir da weiter helfen?


Nachtrag: Wenn ich aus dieser Queue eine Antwort verfasse zB. Leere Antwort, steht dort in der Anrede der korrekte Name drin. Am Attribut selbst scheint es also nicht zu liegen.


MfG

Alex

[MAKUT]

Hallo zusammen,

der Umzug + Updates ist erfolgreich abgeschlossen.

Alles läuft wie es soll, keine schwerwiegenden Fehler.
Unsere Mitarbeiter ergötzen sich an einem rund erneuerten und vor allem deutlich schnelleren Ticketcenter

Vielen dank nochmal für eure Hilfe. Ich werde mich sicher noch 1 2 mal mit doofen Fragen zu Wort melden, aber dann in einem neuen Thread.


Beste Grüße

Alex.