#2328 closed Fehler (fixed)
CRM ignoriert Umstelung der Benutzersprache auf Englisch
| Erstellt von: | andreas.rudin@… | Verantwortlicher: | m.bunkus@… |
|---|---|---|---|
| Priorität: | normal | Meilenstein: | |
| Komponente: | kivitendo ERP | Version: | |
| Schweregrad: | normal | Stichworte: | |
| Beobachter: | andreas.rudin@… |
Beschreibung
CRM-Version: aktuelle Unstable aus git
Wenn ich in der ERP unter
Programm - Benutzereinstellungen - Anzeigeoptionen
die Sprache auf "English" umstelle,
So erscheinen in der ERP alle Menüs etc. auf Englisch, während die Menüs in der CRM weiterhin auf Deutsch angezeigt werden.
Anhänge (1)
Änderungshistorie (23)
comment:1 Geändert vor 20 Monaten durch m.bunkus@…
- Komponente von kivitendo CRM nach kivitendo ERP geändert
comment:2 Geändert vor 20 Monaten durch Ciatronical
Das Menü wird von der ERP fast* korrekt erzeugt.
Das Menu wird in der $_SESSION der CRM gespeichert und bleibt
so lange erhalten, wie $_SESSION existiert.
Unter CRM -> Admin -> Status kann die Session gekillt werden
und schon wird auch das aktuelle Menü der ERP geladen.
Die ERP müsste beim Menü-Wechsel also die Session der CRM löschen
oder die inc/stdLib.php der CRM müsste bei jedem Aufruf testen ob
sich das Menü der ERP geändert hat.
comment:3 Geändert vor 20 Monaten durch m.bunkus@…
Die ERP kann die CRM-Session nicht modifizieren, zumindest nicht ohne riesigen Hack, da PHP-Sessions nicht in einer Datenbank sondern im Dateisystem gespeichert werden. Sprich die ERP müsste raten, wo das ist, und das ist von Installation zu Installation, von Distribution zu Distribution und von Aufrufmethode zu Aufrufmethode (Apache mod_php? PHP-FCGI? PHP CGI?) unterschiedlich.
comment:4 Geändert vor 20 Monaten durch Ciatronical
Ich habe da eine einfache Lösung:
Die ERP bekommt in config/kivitendo.conf
eine zusätzliche Zeile
kivitendo-crm = 0
Wird diese gesetzt so wird beim Speichern der Benutzerkonfiguration der ERP, die CRM-Session zerstört.
Das geht so: Ist kivitendo-crm == 1 so wird ein Template mit folgendem Inhalt aufgerufen.
Pseudocode:
<html>
<?php
//aus crm/delsess.php
while( list($key,$val) = each($_SESSION) ) {
unset($_SESSION[$key]);
}
//zurück zur ERP
echo '<script type="text/javascript">window.location.href="login.pl?action=company_logo";</script>';
?>
</html>
Zweitens:
Ist krivitendo-crm == 1 so wäre es wünschenswert das zur ./menu.ini zusätzlich die ./crm/menu.ini eingelesen wird. Dann hätte das nervige gepatche ein Ende.
Drittens:
Zu guter Letzt würde bei gesetzter kivitendo-crm in den Auftrags-, Angebots-, und Rechnungsmasken ein keiner AJAX-Request eingebaut der in Inhalt des crm/update/is_form_footer.patch aus einer Php-Datei der CRM nach-lädt. Diese Datei sorgt lediglich für einige zusätzliche Button in den Auftrags-, Angebots-, und Rechnungsmasken. Siehe: crm/update/is_form_footer.patch
Diese kleine Zeile am Ende der kivitendo.conf würde also gleich drei Problem lösen.
comment:5 Antwort: ↓ 7 Geändert vor 20 Monaten durch m.bunkus@…
- Nein, sorry. Es sollte für die CRM trivial sein festzustellen, ob sich die Sprache geändert hat, z.B. Sprache in der Session speichern, bei jedem Aufruf die in den Benutzereinstellungen gespeicherte Sprache mit der in der Session vergleichen. Falls unterschiedlich: Session aufräumen. Aber das ist eine CRM-interne Angelegenheit, um die sich die ERP nicht kümmern wird.
- Ja, das ist sinnvoll, werde ich vielleicht demnächst einbauen.
- Äh... garantiert nicht so, wie von dir beschrieben. Wenn du zusätzliche Buttons in der Rechnungsmaske haben willst, dann ist das kein Problem, aber nicht so, wie du's skizzierst, sondern (rein ERP-seitig!):
a) Für die HTML-Templates wird eine weitere Variable zur Verfügung gestellt, über die abgefragt werden kann, ob die CRM installiert ist (trivialer Check über Existenz vom Verzeichnis "crm").
b) In dem HTML-Template für die Rechnung werden entsprechend Buttons eingebaut, sofern die bei a) erwähnte Variable wahr ist.
Wir können gerne a) machen, aber für b) hätte ich gerne einen Patch, der zum Einen übersetzbar ist (keine hardgecodeten Sachen wie "Etikett") und zum Anderen ordentlich HTML-escapet. Als Beispiel kann der Rest von dem HTML-Template dienen, dafür musst du nicht ein Stück Perl können.
Roundtrips in die CRM, nur um irgendwelche HTML-Schnipsel abzuholen oder um der CRM hinterherzuräumen, sind für mich nicht akzeptabel, weil sie ein ohnehin schon nicht ganz harmloses System noch komplexer machen. Aus Support eine extrem unschöne Situation, vor allem, wenn sie ohne großen Mehraufwand vermeidbar ist.
comment:6 Geändert vor 20 Monaten durch hli@…
Hmm, wie oft wird die Sprache eigentlich umgestellt?
Alle 10 Minuten? Oder nur EIN mal?
Die CRM speichert die eingestellte Sprache. Aber diese holt sie nur einmal ab.
Sicher kann bei jedem Zugriff geprüft werden ob sich die Sprache geändert hat, ist das aber wirklich wichtig?
Nichts desto Trotz. Das Menü baut die ERP. Und die ERP-Session lebt ja sicher weiter.
Umstellen der Sprache ist in der CRM nicht vorgesehen. Doppelte Einstellung. Daher machen wir da nichts.
Was Sache der CRM ist, ist die Übersetzung der Maske in die Fremdsprache. Das macht sie.
Sobald die Daten der Session aktualisiert sind. Und das mache wir beim Anmelden, killen der Session, updaten der Usereinstellungen in der CRM.
Umstricken an der Kivi.conf halte ich nicht für Sinnvoll.
comment:7 als Antwort auf: ↑ 5 Geändert vor 20 Monaten durch Ciatronical
- Äh... garantiert nicht so, wie von dir beschrieben. Wenn du zusätzliche Buttons in der Rechnungsmaske haben willst, dann ist das kein Problem, aber nicht so, wie du's skizzierst, sondern (rein ERP-seitig!)
Ich hatte dabei im Hinterkopf dass der Mainstream der CRM-Benutzer lediglich den CRM-Button benötigt. Die restlichen Button wollte ich, wie in der CRM jetzt auch, abschaltbar haben.
if ( $_SESSION['DHL_BUTTON'] ) ......
Das ist sicher auch ERP-seitig möglich. Wichtig ist der äußerst nützliche CRM-Button. Wer den einmal benutzt hat, möchte ihn nicht mehr missen. Die restlichen Button kann man notfalls auch via Patch einspielen oder ERP-seitig abschaltbar machen.
comment:8 Geändert vor 20 Monaten durch m.bunkus@…
Das "Problem" ist, dass die crm/update/menu.ini sämtliche Strings hardgecodet in Deutsch verwendet. Und da es für keinen der Strings in der ERP eine Übersetzung ins Englische gibt, wird halt weiter der deutsche String direkt aus der crm/update/menu.ini angezeigt.
Sinnvoll wäre es, besagte menu.ini auf Englisch umzustellen (Job der CRM-Entwickler) und der ERP beizubringen, dass sie die Strings als Übersetzungen enthält, die in der CRM-menu.ini stehen.
comment:9 Geändert vor 20 Monaten durch m.bunkus@…
Geändert vor 20 Monaten durch Ciatronical
comment:10 Geändert vor 20 Monaten durch Ciatronical
Das Problem sollte mit dem Commit 1d7e46 und dem angehängtem Patch für die ERP gelöst sein.
comment:11 Geändert vor 20 Monaten durch m.bunkus@…
Danke für den Patch, der ist schon einmal sehr gut. Das Problem ist damit noch nicht zu 100% gelöst, weil die locale/XX/all immer neu gebaut wird -- und zwar aus allen zu übersetzenden Strings in allen Quelldateien. Da das CRM-Menü bisher nicht Bestandteil der ERP-Quellen ist, werden die Übersetzungen beim nächsten Lauf von scripts/locales.pl wieder herausfliegen.
Ich sehe dafür zwei Möglichkeiten:
- Das CRM-Menü aus den CRM-Quellen fest in die ERP-Quellen verschieben und nur dann einlesen, wenn auch der Rest der CRM im Verzeichnis crm zu finden ist.
- In irgend einer Datei in den ERP-Quellen alle im CRM-Menü vorkommen zu übersetzenden Strings einmal so aufführen, dass scripts/locales.pl die Strings findet.
Mir gefällt 1. deutlich besser als 2., aber dazu würde ich gerne auch einen Kommentar von eurer Seite haben. Variante 1. bedeutet für euch CRM-Entwickler, dass ihr bei Anpassungen der CRM-Menüstruktur in einen Commit in den ERP-Quellen machen müsst. Variante 2 bedeutet das auch, allerdings müssten die Änderungen dann immer an zwei Orten gemacht werden, was ein garantiertes Rezept für Divergenz ist.
comment:12 Geändert vor 20 Monaten durch hli@…
- ist für mich ok, da hier nicht viel geändert wird.
Muss dann sicher anders benannt werden. menu_crm.ini??
Wir können es auch in der update/menu.ini belassen und einen Link in die ERP erstellen?
Oder aber von Haus aus in der menu.ini.
Gibt es keine CRM, dann ist der Punkt bei der Gruppe nicht aktiv.
comment:13 Geändert vor 20 Monaten durch m.bunkus@…
Ja, die wird anders benannt -- allerdings werde ich gleich mal innerhalb der ERP auch die menu.ini verschieben. Ich entferne sie dann auch gleich aus der CRM (also sowohl update/menu.ini als auch update/menu.ini.patch).
Separate Dateien für ERP und CRM zu haben, macht es mir einen Tick einfacher (weniger Code), als wenn ich alle Punkte in genau einer menu.ini hätte.
comment:14 Geändert vor 20 Monaten durch Ciatronical
Kann locals.pl nicht einfach nachschauen ob es das Verzeichnis crm/ gibt??
Wenn ja dann wird crm/updates/menu.ini und eine Datei mit den Übersetzungen
(beide befinden sich in der CRM) von locals.pl mit eingelesen.
comment:15 Geändert vor 20 Monaten durch s.schoeling@…
Kann es, aber wenn dann ein Entwickler die locales.pl ausführt der kein crm hat, schmeisst es alle Übersetzungen aus der crm sofort wieder raus. Checkt der das ein geht euer kram kaputt.
Erwähnte ich, dass ich ohne crm entwickle?
comment:16 Geändert vor 20 Monaten durch m.bunkus@…
Wenn ihr eine separate Übersetzungsdatei maintainen wollt, die ... dann macht halt das. Mir ist das verhältnismäßig egal. Diese Datei würde dann aber nicht von locales.pl eingelesen, sondern bei der Initialisierung vom ERP-Locale-System. Es muss dann für jede unterstützte Sprache in der CRM eine entsprechende Datei geben, die dasselbe Format hat wie die all in der ERP. Also beispielsweise
crm/locale/de/all crm/locale/en/all ...
Oder eine Stufe einfacher (die anderen Dateien in dem Verzeichnis werden schließlich nicht benötigt):
crm/locale/de crm/locale/en ...
Die crm/locale/de muss dann halt dasselbe Format haben wie in der ERP die locale/de/all. Etc. Und ihr müsst selber dran denken, bei Änderungen der crm/update/menu.ini all eure Übersetzungsdateien anzupassen.
comment:17 Geändert vor 20 Monaten durch Ciatronical
Nein, das ist definitiv zu aufwendig.
Ich bin für Variante 1.
comment:18 Geändert vor 20 Monaten durch Ciatronical
Ist es nicht vlt generell sinnvoll das Menü in die DB zu packen??
comment:19 Geändert vor 20 Monaten durch s.schoeling@…
Ist für das aktuellen Fall irrelevant ob das Menü in der DB oder auf der Platte gespeichert wird. Da das aber statische Daten sind sehe ich da keinen Sinn drin, es sei denn Du willst aus irgendeinem Grund den Leuten erlauben Menüpunkte frei hin- und herzuschieben.
comment:20 Geändert vor 20 Monaten durch m.bunkus@…
- Lösung auf fixed gesetzt
- Status von new nach closed geändert
- Verantwortlicher auf m.bunkus@… gesetzt
Da das komplette Menü inklusive der CRM-Einträge vom ERP-Code gerendert wird, ist das der ERP anzulasten.