Ressourcenreservierungsproblem

    hallo experten,
    ein neuer tag - ein neues problem... oder zwei..


    1. eine kollegin plant eine besprechung mit raumreservierung; sie wählt den raum nicht über "Raum suchen" aus, sondern wählt ihn aus dem adressbuch aus(amrechten rand der einladungsmaske neben "Wo")
    obwohl der raum belegt ist, lässt sich die einladung speichern und versenden. erst danach bekommt sie eine mail mit dem hinweis, dass der raum zur gewünschten zeit belegt ist.
    liegt es an einer fehlerhaften einstellung an irgendeiner stelle, dass notes nicht erst den raum prüft und dann die einladungen verschickt?


    2. alternativ erst auf raum suchen geklickt , fehlermeldung "variant does not contain a container" erscheint, klick auf ok, in der dann erscheinenden suchmaske ist als verzeichnis nicht das dd eingetragen, sondern ein zusätzliches adressbuch, das über einen notes.ini-eintrag einer gruppe von usern zur verfügung gestellt wird. der klick auf suchen bringt dann natürlich als ergebnis auch keinen freien raum.


    ich hoffe, dass jemand rat weiß.


    gruss
    jürgen

    Mail-Cluster 2 x ND 8.5.3 FP3 , 2200 Clients 8.5.3, je 1 SMTP-IN/SMTP-Out ND 8.5.3,
    Anwendungscluster (2 x ND 8.5.3), interne SMTP-Sender (2xND 8.5.3)

    zu 1)


    Notes behandelt den Raum und die Eingeladenen gleichermaßen, für die Maske ist der Raum nur eine zusätzliche "Person". Ich kann auch Personen einladen obwohl sie keine Zeit haben. Insofern liegt der Fehler beim Benutzer. Schließlich sollte jeder Benutzer bevor er eine Einladung losschickt sich bemühen auch einen Termin zu finden, an dem möglichst alle Eingeladenen - insbesondere der Raum - frei sind.


    Zu diesem Zweck ist in der Einladungsmaske der Planer eingebaut, ein mächtiges Tool, das nicht nur zeigt ob und wann jemand Zeit hat sondern mit einem Klick sucht dieser Planer vollautomatisch den nächstmöglichen freien Termin für alle Eingeladenen inklusive des Raumes.


    zu 2) Der Client merkt sich das zuletzt verwendete Adreßbuch in der aktuellen Arbeitsumgebung. Die Maske weiß nicht welches das richtige ist und sucht daher zuerst im aktuell verwendeten...mit ein wenig Aufwand sicher kein unlösbares Problem wenn es wirklich so extrem störend sein sollte.

    Zu 1)
    Du hast natürlich Recht was die Vorgehensweise des Benutzers anbelangt. Allerdings ist es nicht so tragisch wenn ein Eingeladener an der Besprechung nicht teilnehmen kann, als wenn der "Raum nicht teilnehmen kann".
    Müssen sich die Benutzer halt dran gewöhnen erst nach dem verfügabren Raum zu suchen


    Zu 2)
    Das habe ich auch vermutet, aber dann habe ich extra vorher mal das ServerAdressbuch geöffnet, trotzdem stand in der Suchmaske anschließend das andere Adressbuch drin. Schlimmer ist, dass das Feld ausgegraut ist, ich kann also auch kein anderes Adressbuch auswählen (hatte ich wohl nicht erwähnt).
    Das irgendetwas nicht stimmt zeigt wohl auch die Fehlermeldung, die vorher erscheint und die ich mir auch nicht erklären kann.

    Mail-Cluster 2 x ND 8.5.3 FP3 , 2200 Clients 8.5.3, je 1 SMTP-IN/SMTP-Out ND 8.5.3,
    Anwendungscluster (2 x ND 8.5.3), interne SMTP-Sender (2xND 8.5.3)

    ok, ich hab nochmal geschaut welche aktion du genau meinst.


    ich hatte eigentlich das normale adressfenster gemeint aber an dieser stelle wird etwas anderes verwendet. im quellcode sehe ich, daß alle dem client zur verfügung gestellten adreßbücher durchlaufen werden (also via notes.ini, masteradreßbuch bzw. directory-assistance oder directory catalog), diese geöffnet und auf das flag "public address book" geprüft werden. anschließend werden alle dabei übriggebliebenen nach ressourcen durchsucht und die auswahllisten gebaut. zuguterletzt wird das erste in der liste als default ausgewählt.


    daraus folgt:
    - euer zusätzliches adreßbuch (via notes.ini) basiert auf der schablone des DD, kommt also in die auswahlliste.
    - euer zusätzliches adreßbuch (via notes.ini) ist, da die notes.ini-einträge als "lokale adreßbücher" behandelt werden, vor den richtigen einträgen in der liste aufgeführt und damit logischerweise automatisch vorausgewählt. in "normalen" umgebungen wäre es das DD, da dieses zuerst steht (immer dran denken, wir reden von öffentlichen, nicht von persönlichen directories)
    - ich vermute weiterhin, ihr habt am zusätzlichen adressbuch "gebastelt" sodaß ein paar standard views für ressourcen etc dort nicht zur verfügung stehen und dies wiederum verursacht den fehler.


    lösungsvorschlag:
    das zusätzliche adressbuch sollte von der schablone des persönlichen adressbuchs abgeleitet werden anstatt der des DD. alternativ könnte man mit einem hack die IsPublicAddressBook-Property beseitigen und damit die db aus der suchliste des R&R-Fensters entfernen aber das wäre nicht meine favorisierte lösung da ich prinzipiell solang es irgendwie geht auf sowas verzichten würde.