Lotus Notes / Domino 10 > ND10: Administration & Userprobleme

Zugriff & Delegierung - Zugriff auf Kontakte funktioniert nicht

(1/2) > >>

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:

--- Zitat ---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.
--- Ende Zitat ---

Bin gespannt wie sie das lösen.

Navigation

[0] Themen-Index

[#] Nächste Seite