Zugriff & Delegierung - Zugriff auf Kontakte funktioniert nicht

[Manfred W.]

Hallo,

es sieht so aus, als ob HCL das neue Feature in Notes 10 verbockt hat, mit dem man Zugriff auf Kalender und Aufgaben ohne Kontakte vergeben kann.
Das ganze wurde mit einer neuen Rolle [AccessContacts] in der ACL gelöst. Die Kontakte haben ein neues Feld "Readers" (ohne $), in dem die Rolle eingetragen ist.

Wenn man nun jemandem das Recht "Kalendereinträge, Aufgaben oder Kontakte lesen, erstellen, bearbeiten und löschen" gibt, dann hat derjenige in der ACL "Kein Zugriff", Öffentliche Dokumente lesen, Öffentliche Dokumente schreiben und die neue Rolle [AccessContacts]. Die Kontakte sind aber so nicht sichtbar.
D.h. egal ob man Zugriff mit oder ohne Kontakte vergibt, die Kontakte sind nicht sichtbar.

Erweitert man den Zugriff auf Mail, so dass derjenige in der ACL Leser, Author oder Editor ist, dann sind mit der Rolle [AccessContacts] auch die Kontakte sichtbar.

Es sieht so aus als ob die Rolle [AccessContacts] nicht greift, wenn man keinen Zugriff hat, sondern nur Öffentliche Dokumente lesen/schreiben.

Das Verhalten haben wir sowohl mit der deutschen als auch englischen Mailschablone 10.

Fassungslos macht mich, dass das HCL beim Testen nicht aufgefallen ist. Wenn man da ein neues Feature einbaut, dann muss man das auch gezielt testen.

Ticket bei HCL ist offen (CS0091573).

Grüße
Manfred


EDIT:
So wie HCL das umgesetzt hat, kann das gar nicht funktionieren:
https://www.ibm.com/support/knowledgecenter/SSVRGU_10.0.1/basic/H_ABOUT_RESTRICTING_ACCESS_TO_SPECIFIC_DOCUMENTS_USING_A_READERS_FIELD.html
Da kann man nur mit dem Kopf schütteln.

[CarstenH]

Da ich gerade erst den ersten 11er Testserver aufsetze war mir die neue Kontaktoption noch gar nicht aufgefallen - egal wie man es dreht kann das in der angedachten Form gar nicht funktionieren.

Leser- (und Autorenfelder) funktionieren NIE mit niedrigeren ACL-Rechten als der Name besagt.

Das sind Grundlagenkenntnisse aus den Entwickler- und Adminkursen!
Kopfschütteln trifft es nicht mal ansatzweise, Kopf-meets-Tischplatte schon eher!

Was (ohne kompletten Umbau des Berechtigungsmodells) gerade noch gehen würde:
a) Kontakte noch als zusätzliche Option bei erlaubten Mailzugriffsrechten anzubieten (klingt gerade noch halbwegs sinnvoll)
b) Kontakte als "Öffentliche Dokumente" zu markieren und damit automatisch den Kalendernutzern zugänglich zu machen (eher eine blöde Idee)

Schon die Kalenderzugriffe mit öffentlichen Dokumenten sind nämlich keine so tolle Idee, wenn man die Schreibrechte dazu vergibt.
Was viele nicht wissen, die Schreibrechte auf öffentliche Dokumente beinhalten auch immer deren Löschrechte, da die ACL-Option erst ab Autor greift.
Wenn dann nämlich Einträge verschwinden ohne dass irgendjemand Löschrechte hat … lassen wir das.

Ich persönlich finde, dass die Trennung via separatem Adressbuch (also das, was bei Roaming Nutzern Standard ist) noch die sinnvollste Variante darstellt, damit kann man:
- Kontakte, bei Bedarf sogar nur bestimmte, weiteren Nutzern zugänglich machen, auf Wunsch getrennt mit Lese-, Schreib- und Löschrechten;
- aus dem Domino Verzeichnis übernommene Namen bei Umbenennungen automatisch vom AdminP korrigieren lassen;
- Geburtstagskalender lassen sich separat einbinden;
- Admins haben bei Bedarf Zugriff auf Verbindungs- und Arbeitsumgebungsdokumente, Zertifikate;
...und das alles ohne eine einzige Zeile neu programmieren zu müssen (okay, eine View für die Geburtstage).
Da muss aber ansonsten nichts neu erfunden werden! Alles schon da und funktioniert.

Lediglich für die iNotes-Nutzung müsste man hier Hand anlegen, hier bräuchte man mal Nutzungsstatistiken, welche Clients (und Features) wie stark genutzt werden.

Meine 5 Cent dazu.
Carsten

[Manfred W.]

Hallo,

hier die Schritte zum nachvollziehen des Problems, die ich auch an den Support weitergegeben habe:
Neue Maildatenbank mit der Mailschablone 10 erstellen (deutsch oder englisch ist egal).
Sicherstellen dass man selber der Owner ist.
Einem zweiten User (Testuser) Schreib-Zugriff auf Kalender, Aufgaben und Kontakte (ohne Mail) geben ("Kalendereinträge, Aufgaben oder Kontakte lesen, erstellen, bearbeiten und löschen").
Einen Kontakt in der Maildatenbank anlegen.

Dann die Maildatenbank mit dem zweiten User öffnen und zu den Kontakten wechseln. Der Kontakt ist nicht sichtbar.
Den zweiten User dann einen Kontakt anlegen lassen. Selbst den kann er dann nicht sehen.

Wenn man selbst wieder in die eigenen Kontakte rein schaut, sind beide Kontakte sichtbar.

Grüße
Manfred

[CarstenH]

So bitter es klingt, da braucht man nichts nachzuvollziehen, hier sind grundsätzliche Basics aus Notes im Spiel, die sich seit über 20 Jahren nicht geändert haben!

Der Delegierungszugriff auf Kalender und Aufgaben wurde vor vielen, vielen Jahren so gelöst, dass jeder Kalendereintrag als "Öffentlich" markiert ist => $PublicAccess="1"

Der Zugriff auf Mails stammt aus der Gründerzeit von Notes und setzt hingegen mindestens Leserzugriff voraus, der ÜBER dem öffentlichen Zugriff steht und diesen  beinhaltet.

HCL musste sich also entscheiden: will ich dem Nutzer Mails zugänglich machen? Nein? Dann nur Zugriff über "öffentliche" Dokumente. Dabei gibt es aber kein "Feintuning" über Leserfelder da diese erst ab dem Zugriff der Ebene Leser greifen.

Ergo kann man auch nicht zwischen Kalender, ToDo und Kontakten unterscheiden, alles oder nichts ist hier die Devise. Falls HCL hier nicht an die seit der Steinzeit geltenden Zugriffsebenen und -Berechtigungen rangeht gibt es da keinen Kompromiss! Lösungsansätze hatte ich in meinem letzten Beitrag schon beschrieben - das ist kein Fehler, den man mal eben mit einem Fixpack beseitigen könnte.

</IRONIE>...es sei denn alle Mails und Kontakte in jeder Mailbox bekommen plötzlich nachträglich Leserfelder die den Zugriff verhindern, die sich natürlich jedesmal mitändern wenn ein Besitzer jemandem Zugriffe erteilt oder entzieht...dann wären die Zugriffsänderungen jedesmal ein Fall für den AdminP mit tausenden Dokumentänderungen je Mail-DB</IRONIEOFF>

Carsten

[Manfred W.]

Support:

The above issue I have already collaborated with the Development team and team is working on this via  SPR#SKUEBJBE9Y. The issue has been considered to be fixed in a future release unless it does not hamper the existing functionalities.

Bin gespannt wie sie das lösen.

[maxritti]

Guten Morgen zusammen,

wie habt ihr das Problem gelöst?
Einfach die Rolle bei den Benutzern wieder entfernen?

Ich frage, weil wir aktuell seit gestern offensichtlich auch das Problem haben.
Derzeit noch 9er Server, Mailfile und Client aber bereits teilweise 10.

Ein Benutzer hat gestern wohl Rechte vergeben und daraufhin hat der AdminP die ACl angepasst.
Und da sieht es für mich so aus, als wenn "nur" die Rolle hinzugefügt wurde.

Naja, ich teste es einfach mal, Rolle weg und schauen ob es klappt.

[maxritti]

War zu früh heute morgen.
Wie Carsten bereits schrieb, nicht wirklich trivial. 

[CarstenH]

wie habt ihr das Problem gelöst?
Einfach die Rolle bei den Benutzern wieder entfernen?

Ein Benutzer hat gestern wohl Rechte vergeben und daraufhin hat der AdminP die ACl angepasst.
Und da sieht es für mich so aus, als wenn "nur" die Rolle hinzugefügt wurde.

tldr: [AccessContacts] nur dem Besitzer und den Servern lassen und die Kontaktfreigabe ansonsten nicht nutzen. /tldr

Langfassung:

Ich hab mir das samt AdminP jetzt mal angeschaut und HCL hat sich doch tatsächlich für die von mir als b) bezeichnete Variante entschieden, sprich: alle Kontakte sind nach der Synchronisation mit der Mail-Anwendung automatisch öffentlich. Oder wie ich es genannt habe: Blöde Idee!

Die Rolle [AccessContacts] selbst wird (zumindest in meinem Testszenario) in der ACL allen Nutzern gegeben, die in irgendeiner Form auf die Kontakte zugreifen dürfen/sollen. Das schließt auch den Besitzer und alle Server mit ein, auf denen die DB liegt. Die Rolle konnte ich im Design in etlichen Hide-When-Formeln u.a. von gemeinsamen Aktionen finden, d.h. man sollte die Rolle keinesfalls komplett aus der DB entfernen sonst kann man sich gleich von Teilen des Designs mit verabschieden.

Da die Kontakte (bzw. deren Kopie in der Maildatenbank des Eigentümers) eigentlich immer öffentlich sichtbar sind werden Sie an einigen Stellen über das Feld ExcludeFromView simpel versteckt, das Readers-Feld greift bei öffentlichen Dokumenten sowieso nicht. Dennoch beinhaltete das Readersfeld in meinem Test bei Privatkontakten den Besitzer und LocalDomainServers und war in anderen Fällen entweder nicht vorhanden oder leer. Warum Bei Manfred [AccessContacts] in (einigen?) drin steht konnte ich bei mir nicht nachvollziehen, weder bei Kontakten die VOR der Berechtigungsänderung angelegt wurden noch bei nachträglich erstellten.

Alles in allem ist die ganze von HCL neu eingebrachte Kontakt-Funktionalität in der aktuellen Umsetzung extrem unausgegoren und definitiv nicht benutzbar.

Carsten

[Manfred W.]

Also das mit den Kontakten ist echt merkwürdig. Warum bei Carsten die Rolle im Readers Feld gar nicht auftaucht kann ich mir wiederum nicht erklären.
Bei allen Testdatenbanken und produktiven Maildatenbanken, mit denen wir das Problem nachgestellt haben, ist die Rolle [AccessContacts] im Feld Readers.

[maxritti]

Bei uns ist es so, dass sowohl bei dem User, der das Problem gemeldet hat und ein Testuser in bestehenden Kontakten das Feld Readers erhält, das aber leer ist.

Strange in der Tat.