Neue Features: Chance auf Merge?

[jgruenewald]

Hallo liebes EGroupware-Team,

bei uns im Unternehmen gibt es Anfragen zu zusätzlichen Features/Verbesserungen (für die aktuelle EGW 19.1), die z.T. in unserer alten Installation (1.8) noch enthalten waren und zum anderen damals von uns selbst in den Code gepatched wurden.

Nun wollte ich kurz nachfragen, ob diese CR’s eine Chance auf Merge haben und wir unter Einhaltung der Guidelines die Changes implementieren und einen MR stellen.

1. Ganztägige Termine als "Ein-Zeiler"
   In (Thunderbird)-Lightning werden ganztägige Termine grundsätzlich als einzeilige Einträge im Kopf dargestellt, bei EGroupware ist dies nur bei nicht-blockierenden Terminen der Fall. CR sieht vor in den Benutzereinstellungen einen Toggle bereitzustellen, der es jedem User ermöglicht diese Darstellung auch für blockierende Termine zu aktivieren.
   
   
   
   Hintergrund:
   Bei größeren Teams gibt es oft eine Häufung ganztägiger Termine (Urlaub, Berufsschule, Krank, etc.), da diese sich aber dann in der Ansicht über den ganzen Tag erstrecken wird es schnell unübersichtlich. Deswegen wäre es also hilfreich sich mehr Übersicht verschaffen zu können.
2. Anzeige von Teilnehmern auf einem Termin
   Wer an welchem Termin teilnimmt wird erst angezeigt, wenn man mit der Maus über den Termin fährt. Gerade bei Terminen wie “Urlaub” wäre es aber praktischer, wenn der Teilnehmer der Termins direkt in der Kalenderansicht neben dem Titel des Termins mit angezeigt würde. Dies gilt dann für Termine sowohl mit 1 als auch mehreren Teilnehmern. Auch diese Einstellung sollte über einen Settings-Toggle für jeden User ein- und ausschaltbar sein.

Das war’s auch schon.
Alles Gute und bleibt gesund (und falls möglich zu Hause ).

Gruß
Jan

[RalfBecker]

Im Prinzip ja

Problem ist das es im Kalender einfach schon viel zu viele Optionen gibt

@bbegw was meinst Du?

Es sollten auf jeden Fall auf den aktuellen Wert erzwungene Einstellungen sein, damit es zu mindest in neuen Installationen nicht noch mehr Einstellungen werden.

Andere Möglichkeit wäre gar keine Einstellung, sondern bei der Anzeige von mehr wie einem Benutzer (der sollte ja nichts neben seinem ganztägigen blockierenden Termin haben), die blockierenden Termine wie die nicht blockierenden anzuzeigen.

Ralf

[bbegw]

Hallo Jan und Ralf,
an sich spricht für mich auch nichts dagegen, gerade der Punkt 1 kommt häufiger vor und ich wäre sogar versucht zu sagen, das hier 3 Optionen mehr Sinn machen:
Anzeige von ganztägig blockierende Terminen:

• alle ganztägig blockierende Termine oben in der Kopfzeile anzeigen
• nur Termine mit/bei eigenem Benutzer soll Kalender blockieren, Rest oben
• alle ganztägig blockierenden Termine, werden als blockierend angezeigt

Formulierung braucht noch etwas “Hirnschmalz”, damit es verständlich genug, aber auch nicht zu lange ist.

Würde ich dann im Tab “Konfiguration” der Kalender-Einstellungen platzieren. Hierbei fände ich es auch nicht “schlimm”, wenn es nur als Voreinstellung auf der 3. Option sitzt und nicht erzwungen.

Punkt 2 sehe ich einfach schwerer umzusetzen in der Darstellung, da die Spalten in der Regel eher zu kurz sind. Aber wenn ihr dafür gute Ideen habt und es gegen Trunk entwickelt, einfach über Github den Request schicken, den gebe ich dann an Nathan weiter zur Prüfung und zum mergen.

Birgit

[jgruenewald]

Hallo Birgit,

danke für den Input. Zu Punkt 2) werde ich versuchen etwas “sinnvolles” beizutragen. Mal schauen ob ich mit einem “ellipsize” hier weiterkomme. Sprich es werden so viele Teilnehmer angezeigt, wie Platz vorhanden (dadurch, dass ganztägige Termine nun alle oben stehen gibt es ja auch ein paar weniger parallele Termine gleichzeitig, was mehr Breite schafft und die Höhe des Termins ergibt sich aus seiner Dauer), was nicht passt wird ausgepunktet.

Bei ganztägigen Terminen könnte man sich quasi als “Kür” überlegen, dass wenn die Option für die Anzeige von Teilnehmern auf dem Termin aktiv ist, diese zumindest 2-zeilig angezeit werden, so dass für den Teilnehmer noch Platz ist.

[jgruenewald]

Guten morgen,

Teil 1 (Verhalten ganztägiger Termine) wäre bereit für den Merge. Die Konfiguration habe ich unter “Einstellungen > Kalendar > Einstellungen der Terminverwaltung” eingepflegt.

Könnte mir jemand kurz verraten, wie ich die Sprachen neu kompiliert bekomme (@RalfBecker ?) , so dass er mir die deutschen Texte anzeigt (die würde ich schon gerne testen). Die deutschen Texte wären wie folgt:

• Anzeigeverhalten ganztägiger Termine
• Alle als Einzeiler
• Alle als Einzeiler (außer eigenen)
• Nicht-blockierende als Einzeiler
• Wie soll ein ganztägiger Termin dargestellt werden?
  Blockierende Termine werden als Block über den gesamten Tag dargestellt, nicht-blockierende Termine als Einzeiler oberhalb der Tagesansicht.

Fragen/Anmerkungen zu den Übersetzungen, bzw. den Texten an sich? (@bbegw ?)

[StefanU]

Hallo Jan.

Bezüglich der Übersetzungen:
Die lang files liegen in
https://github.com/EGroupware/egroupware/tree/master/calendar/lang
Du könntest bei dir die Texte entsprechend in en und de eintragen. Bei einem commit auf GitHub kannst du die Übersetzungen so auch entsprechend mitgeben.

Dass die Übersetzungen verwendet werden, bedingt natürlich den entsprechenden Aufruf im Code.

Um Texte anzulegen und Übersetzungen zu pflegen gibt es auch ein translation tool. Das müsste nachinstalliert werden. Steckt in:
http://download.opensuse.org/repositories/server:/eGroupWare/Debian_10/all/

Das verwenden wir so auf unserem translation server, auf dem Community-Übersetzer Übersetzungen einpflegen.

Ich kann aber auch gerne später die Texte nachpflegen.

Stefan

[jgruenewald]

Hallo Stefan,

danke für die Info. Habe mich vermutlich unklar ausgedrückt. Die lang-files (calendar/lang/egw_de.lang bzw. calendar/lang/egw_en.lang) habe ich bei mir angepasst. Aus mir unerfindlichen Gründen werden aber nur die englischen Texte für die neuen Labels angezeigt. Daher war meine Vermutung, dass ich außer die Dateien zu aktualisieren und Caches zu killen noch etwas anderes machen muss. Weiß nur nicht was

Jan

[RalfBecker]

Neue Übersetzungen werden immer beim Login gelesen, allerdings nur dann wenn die Timestamps der lang-Files tatsächlich neuer sind, als das letzte Einlesen.
Die Übersetzungen werden im Cache gehalten, allerdings nicht im Instanz-Cache, den man im Admin löschen kann, sondern im Tree-Level Cache. Dh. Du musst den Apachen oder PHP-FPM restarten.

Ralf

[jgruenewald]

Änderungen an bestehenden Labels (in egw_de.lang) werden nun dargestellt. Die neu hinzugefügten Labels liegen allerdings weiterhin nur in der englischen Übersetzung vor. Habe ich was übersehen?

Jan

[RalfBecker]

Mach halt mal den Pull Request und dann kann ich drauf schauen.

Ralf

[jgruenewald]

Gerne, habe offenbar nur keine Berechtigung einen Branch und damit einen PR zu erstellen.
(Account: cit-gruenewald)

[RalfBecker]

Du musst das auf einem Fork machen:

https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request

Ralf

[jgruenewald]

PR ist gestellt.

[RalfBecker]

Habe ich gesehen, kann nur nicht überall gleichzeitig schauen und antworten

Ralf

[jgruenewald]

Harre der Kritik, die da kommen mag.
Hast du vielleicht noch einen Tipp, wo die Daten für die “calendar::”-uids in den localStorage geschrieben werden? Bzw. wo gesteuert wird, welche Daten für das et2_widget_event aus der Persistenz gezogen werden?

Hintergrund: Ich möchte ja gerne die Namen der Event-Teilnehmer an das Event schreiben. im et2_widget_event habe ich aber nur Zugriff auf die participants in Form ihrer IDs und die participant_types in Form von fertigem HTML, welches für die Teilnehmer im Tooltip verwendet wird.

Jan

[StefanU]

Hallo Jan.

Hast du vielleicht noch einen Tipp, wo die Daten für die “calendar::”-uids in den localStorage geschrieben werden?

Bitte mache für solche Sachen jeweils einen eigenes Thema in der Kategorie

https://help.egroupware.org/c/developers

auf Englisch auf. So können unsere englisch-sprachigen Entwickler mitschreiben und andere Community-Entwickler haben weltweit etwas davon. Das segmentieren auf kleinere einzelne Fragestellung ermöglicht anderen auch die Zusammenhänge und die Lösungen zu verstehen. Und bitte keinen persönlichen Endlos-Thread produzieren…
Unsere Probleme sind Doku und Entwicklerkapazität. Bei der Doku würden deine Beiträge helfen.

Schau dir bitte auch einmal das

EGroupware/example

und das

an. Anregungen, Hinweise und Verbesserungsvorschläge sind immer willkommen.

Viele Grüße
Stefan

[RalfBecker]

Hi Jan,

gerade gesehen, dass Du da noch eine Frage hattest:

Hast du vielleicht noch einen Tipp, wo die Daten für die “calendar::”-uids in den localStorage geschrieben werden? Bzw. wo gesteuert wird, welche Daten für das et2_widget_event aus der Persistenz gezogen werden?

Hintergrund: Ich möchte ja gerne die Namen der Event-Teilnehmer an das Event schreiben. im et2_widget_event habe ich aber nur Zugriff auf die participants in Form ihrer IDs und die participant_types in Form von fertigem HTML, welches für die Teilnehmer im Tooltip verwendet wird.

Als das Schreiben in den Localstorage passiert in api/js/jsapi/egw_data.js.

Am besten schreibst Du mal auf Englisch im Developer Forum und mention-st Nathan.

Ralf