Alarm immer um 4 Uhr früh

Alarme werden vom Client sowieso erst angezeigt wenn der Nutzer diesen startet. Wenn er also um 8 Uhr den PC anwirft und die Meldung erhält ist es m.E. unerheblich ob die Alarmzeit 4 Uhr oder 7 Uhr lautet.

Viel problematischer wäre es, wenn die Vorgabe z.B. 15 Uhr wäre und der Nutzer aber ausgerechnet an diesem Tag schon 14:30h Feierabend macht - dann wäre der Alarm erst am nächsten Tag fällig und definitiv zu spät.

Man muß übrigens nicht programmieren um die Vorgabe von 1440 Minuten (=1 Tag) zu ändern. Es reicht vollkommen einen anderen Wert einzutragen. So sorgt bspw. der Wert 0,25 dafür daß der Alarm 6h statt 24h vor dem Ereignis eingetragen wird.

Manchmal ists wirklich so simpel...;)

Ganz normal wo man den Wert halt einstellt: In der Mail DB unter Werkzeuge -> Vorgaben -> Kalender -> Alarme

{Off Topic}

Sag mir nochmal daß ich gut bin *gg* Ich hörs doch so gerne

PS: 500er Marke überschritten *lol*

{/Off Topic}

Ich schreib ja schon an einem Agenten der automatisch Posts mit Standardtexten wie z.B. RTFM beantwortet. Wenn ich Taurec eingeholt hab setz ich mich dauerhaft zur Ruhe dann seits mich wieder los Aber gibt ja dann sicher noch andre Foren wo ich Unfrieden stiften könnte *lol*

Welches Alarmfenster erscheint 4 Uhr? Von einem Kalendereintrag der VOR der Änderung angelegt wurde? Oder von einem Kalendereintrag der NACH der Änderung neu angelegt wurde?

Also nochmal langsam. Wir haben es hier mit 2 verschiedenen Zeiten zu tun:

1.) Die Default-Uhrzeit für Ganztägige Ereignisse

2.) Die Vorgabe-Zeit für einen Alarm (für Ganztägige Ereignisse)

zu 1.) Diese Zeit ist mit 4 Uhr im Design des Kalenders vorgegeben und könnte mit etwas Sucharbeit und Aufwand sicher so geändert werden, daß z.B. eine andere feste Zeit oder ein Wert aus dem Vorgabeprofil genommen wird. Wobei dann noch festzulegen wäre was passiert, wenn der Nutzer z.B. einen Termin für Sonntag einträgt aber am Sonntag keine Anwesenheit vorgegeben hat. Du verstehst das Problem...?

zu 2.) Diese Zeit ist ein Offset (in Minuten) zur zeit aus dem Punkt 1., also Vorgabe Terminzeit minus 1d=24h=1440min. Ändert man die Terminzeit ändert sich automatisch auch die Alarmzeit.

Wenn ein Alarmfenster um xx:xx Uhr (frühester Anzeige-Zeitpunkt = Punkt 2.) angezeigt wird dann steht im Text des Alarmfensters die Zeit von Punkt 1 und der Betreff. Also müßte dort nach deinem Beispiel der 2. Oktober 4:00h stehen, was nach meinen bisherigen Ausführungen auch völlig korrekt wäre, da ja nur die Alarm- aber nicht die Terminzeit geändert wurde.

Weiterhin eine Ergänzung: Ich hatte vorgeschlagen einfach einen Wert als Dezimalwert in das Vorgabefenster einzutragen. Ich habs nochmal getestet und dabei festgestellt daß durch einen Mix aus Formel- und Scriptsprache das nur in einem englischen Client funktioneren dürfte, da der deutsche Client als Dezimaltrennzeichen ein Komma, der englische aber einen Punkt verwendet. Damit scheidet diese Form der Vorgabe leider für deutsche Clients aus da erst das Kalenderscript oder das Vorgabefenster so angepaßt werden müßte, daß sowohl Komma als auch Dezimalpunkt korrekt arbeiten. Die Kalender-Maske setzt leider Script ein (und erwartet daher einen Dezimalpunkt) während sowohl das Vorgabefenster als auch der Dialog (Klick auf den Wecker im Kalenderdokument) mit Formelsprache arbeiten und damit das Komma erwarten. Verwendet man den Klick zur Kontrolle ist auch alles korrekt im deutschen Client, nur eben nicht wenn mans vergißt.

Insofern - dank deutsch-englisch-Mix in den Programmiersprachen, wohl doch keine simple Lösung für den deutschen Client ohne Anpassung durch Programmierung.

Also da durch die Trennzeichenproblematik beim deutschen Client die Vorgabe ohne Templateänderung wegfällt gibt es aus meiner Sicht 2 mögliche Lösungen:

a) Templateänderung
Nachteil: Änderungen müssen bei jedem Releasewechsel wieder erneut vorgenommen werden. Gute Dokumentation und Versionsverwaltung hat dabei oberste Priorität.

b) Workaround
Man könnte bspw. mit einem periodischen Agenten alle offenen Alarme korrigieren, sogar ein Zeitabgleich mit dem Anwesenheitsprofil des Nutzers wäre denkbar. Vorteil hierbei wäre, daß der Agent nicht zum Template gehört und demzufolge auch Updates problemlos übersteht.