Raum im Kalendereintrag nachträglich ändern

[kuabuab]

Hallo

Auf einem bestehenden Meeting den Raum zu ändern ist nicht schwer.

Auf den Button: "Einladung speichern und senden"
Es erscheint der Dialog ob der Eingeladen Benutzer informiert werden soll

Wird beim schliessen des Dokuments *nicht Ja gewählt für das Speichern, ist im Kalender der Benutzers der alte Raum eingetragen und in der Räume&Ressourcen Datenbank der neue Raum.

* Ich gehe davon aus, dass das Meeting gespeichert ist! Das Dokument schliessen -> Aber es kommt die Meldung ob man das Dokument speichern möchte -> ich sage Nein, weil ich das ja vorhin vermeintlich schon gemacht habe…


Dieser Verhalten kann ich ca. ab dem Mailtemplate FP8 beobachten.
Wer kennt das auch?


Gruss
Daniel

[oliK]

Hallo,

ich bin heute über das gleiche Phänomen gestolpert.
Seit einigen Wochen häufen sich die Meldungen, dass die Raumbuchungsdaten der Ressourcen-Datenbank
und der lokalen Kalender nicht immer übereinstimmen.
Ändert man manuell einen Raum in der Buchung, so muss man nach dem Drücken von 'Einladung speichern und senden'
nochmal explizit speichern, ansonsten wird die Raumänderung im eigenen Kalender nicht behalten.
Ziemlich übel und ich suche gerade im Design nach entsprechenden Code-Änderungen.
Template 9.0.1 FP9

[J Parlin]

9.0.1er Schablone nehmen ist ein Problem ?

[oliK]

Mit der Schablone 9.0.1 (aus 2013) funktioniert es normal.
Das Problem verhält sich von der GUI folgendermaßen.
Schablone 9.0.1 FP9:
- Raum rausnehmen
- neuen Raum reinnehmen
- Aktion 'Einladung speichern und senden'
- im Dialog auf 'Senden' klicken
- Kalendereintrag wird gespeichert und NICHT GESCHLOSSEN
- in der Kalenderansicht ist noch der alte Raum sichtbar und wird nur übernommen wenn man manuell nochmal speichert

dagegen das Verhalten mit Schablone 9.0.1:
- Raum rausnehmen
- neuen Raum reinnehmen
- Aktion 'Einladung speichern und senden'
- im Dialog auf 'Senden' klicken
- Kalendereintrag wird gespeichert und GESCHLOSSEN
- in der Kalenderansicht ist die Aktualisierung sichtbar

[oliK]

Das Problem besteht in der Funktion ValidateRR der Bibliothek Common_de-DE (bei deutscher Schablone).
Hier wurde etwas im Code umgestellt u.a. die Konstante Const NotesMacroFFRRoomsResources$ in welcher die Formel "@FindFreeResource..." hinterlegt ist.
Relativ weit unten wird diese im Rahmen eines Evaluate genutzt und genau diese wirft nun im meinem Szenario mit FP9 einen Fehler 221.
Dieser wird als vContinue/bContinue = false bis nach ganz oben zurückgegeben, was dazu führt, dass der QuerySave-Event nicht beendet wird.
Daher bleibt das Dokument geöffnet und wird auch nicht gespeichert.
Jetzt muss ich nur innerhalb der Funktion tiefer graben um zu verstehen, was an der Formel nun falsch ist.

Nachtrag:
Schablone 9.0.1 ohne FP:
Const NotesMacroFFRRoomsResources$= "@FindFreeResource(RoomsResources;tmpResourceType1;datetime1;datetime2;0;9999)"
Schablone 9.0.1 FP9:
Const NotesMacroFFRRoomsResources$=|@FindFreeResource(tmpRoomsResources;tmpResourceType1;tmpdateTime1;tmpdateTime2;0;9999;[IgnoreCurrent])|

Wenn ich den letzten Parameter "[IgnoreCurrent]" wegnehme funktioniert es wie gewohnt.

[kuabuab]

Hi Oli

Habe deinen Post leider erst jetzt gesehen... Aber sehr guter Hinweis, danke.

Ich habe ein englisches Template. Die Situation ist die gleiche.

Dein Hack funktioniert.
Aber, der Button heisst ja: Save and Send Invitations
Nun der Button macht jetzt ein: Save&Close and Send Invitations

Damit kein Close passiert, habe ich die Formel auf dem Button etwas umgebaut:

SO:
FIELD tmpAction :="6";
@If(@PostedCommand([FileSave]);@Command([FileSave]);"")

STATT:
FIELD tmpAction :="6";
@If(@PostedCommand([FileSave]);@PostedCommand([FileCloseWindow]); "")

Jetzt funktioniert es so wie es allgemein erwartet wird.


Gruss
Dani

[Peter Klett]

<Klugscheiss>

FIELD tmpAction :="6";
@If(@PostedCommand([FileSave]);@Command([FileSave]);"")

Warum speicherst Du das Dokument zweimal?

FIELD tmpAction :="6";
@PostedCommand ([FileSave])

hätte doch bestimmt auch gereicht

</Klugscheiss>

[oliK]

1) Also der Knopf hat früher schon immer das Dokument beim Speichern geschlossen.
Auch wenn (Schliessen) nicht im Aktionsnamen drin steht.

2) Ich überlege schon, ob es sich hierbei ggf. um ein Versionsproblem handelt.
Wir nutzten nämlich im Client durchgehend 9.0.1 FP8 mit Schablone 9.0.1 FP9 da ich schon an einigen Stellen gelesen habe, dass die dennoch kompatibel wäre.
Nun scheint es mir aber, dass es sich bei dem 'defekten' Parameter ggf. um eine Erweiterung im FP9 handelt, die ältere Clients nicht verstehen? Anders kann ich mir dies gar nicht erklären.

[kuabuab]

@Peter - Das ist mir bewusst und ich habe eine solche Antwort irgend wie erwartet.
Bei:
@PostedCommand ([FileSave])
verhält sich das Dokument anders als bei:
@If(@PostedCommand([FileSave]);@Command([FileSave]);"")

Vielleicht weiss jemand warum? Ich stehe gerade ziemlich auf dem Schlauch.



@Oli
Beim Kunden wo das Problem störend auftritt, ist das sehr ähnlich:
Client 9.0.1 FP7 auf Citrix (Basic)
Mailtemplate: FP9

Aber ich habe die Tests auf Mac und Win10 gemacht, mit dem neusten Client, also FP10. Und das Verhalten war immer das gleiche...


Übrigens - ich finde ein Button sollte schon das machen was drauf steht.

[Peter Klett]

Wenn sich das Verhalten durch das zweimalige Speichern ändert, würde ich das so lassen und mir da keine weiteren Gedanken machen ...

Fiel mir nur so auf

[oliK]

Durch den Hack in der Schablone für FP9 konnte ich zwar das üble Problem des Nicht-Speicherns des Kalendereintrags wegen Formelfehler beheben,
dafür hat sich im Nachgang aber dadurch ein anderes Problem offenbart, welches weniger gewichtig ist aber dennoch störend:
Ändert man von einem bestehenden Termin die Uhrzeit (z.B. von 10-12 auf 10-13) so wird der Dialog angezeigt "Folgende Räume/Ressourcen sind entweder nicht verfügbar oder eingeschränkt: Raum xyz" Vermutlich wird dies in der neuen Schablone über den Parameter "[IgnoreCurrent]" der Formelfunktion @FindFreeResource gesteuert, welchen man aber aufgrund von Fehler nicht nutzen kann. Workaround: Raum rauslöschen, speichern, neu reinnehmen, speichern.

[oliK]

Der Formelfehler ist übrigens 'Operation failed' 221.

[oliK]

Ich habe heute noch ein wenig mit dem Problem herum getestet und in dem Rahmen mal Notes 9.0.1 FP8 durch FP10 ersetzt.
Dort wird die Formel mit dem Parameter "IgnoreCurrent" fehlerfrei ausgeführt, es wäre also prinzipiell keine Anpassung an der Schablone notwendig,
wenn man die FP9-Mailschablone auch nur mit FP9- oder FP10-Client verwendet.
Diese scheint also doch nicht mit älteren Clients vollständig kompatibel zu sein, da dort (zumindest unter FP8) der 'neue' Parameter nicht erkannt wird und zum Formelfehler und den Folgeproblemen führt.
Dies sollte ggf. allen Beteiligten bewusst gemacht werden. Auch von eknori kam die Aussage, dass es kompatibel wäre.
Die Probleme sind halt nicht offensichtlich, können aber ganz schönen Ärger einbrocken.