Das Notes Forum
Domino 9 und frühere Versionen => Entwicklung => Thema gestartet von: TMC am 02.03.04 - 20:14:56
-
Hi,
mit folgendem Code
Dim vMailReceiver As Variant
Set docprofile = db.GetProfileDocument("profile_A")
vMailReceiver = docprofile.setup_Receiver 'Emailempfänger
docMail.SendTo = vMailReceiver
lese ich den Inhalt eines Profildokumentes aus. Klappt auch wunderbar wenn ich das mache (als DB-Manager).
Mache ich es über eine andere ID, die Editor-Rechte hat, kommt eine Fehlermeldung (sinngemäß) "Sie haben keine Berechtigung, auf das Profildok zuzugreifen".
In der Maske des Profildoks habe ich keine Einschränkungen (Leser/Autorenfelder), die Maskeneigenschaften sind auch Default, jeder sollte also lesen dürfen.
Ist das mal wieder so eine Eigenart von Profildokumenten? Oder wo könnte sonst noch eine Lesesperre vorliegen??
Ich bin kurz drauf und dran, das Profildok rauszuwerfen und ein normales Dok draus zu machen. :-\
Matthias
-
... aus der hilfe:
Ein Benutzer benötigt mindestens Autorenzugriffsrecht in der Zugriffskontrolliste einer Datenbank, um ein Profildokument zu erstellen, das für alle Benutzer verfügbar ist.
sind da evtl. leser/autorenfelder drinne ?
-
Moin KLaus, WACH WERDEN !!
TMC hat EDITOR Rechte und KEINE Leser-/Autorenfelder :D
-
@ulrich,
ja ja, ist halt noch a bisserl früh :P
Abär:
Benutzer mit mindesten Editorzugriff können ein Dokument bearbeiten, wenn folgende Bedingungen erfüllt sind:
Sie sind in Leserzugriffsliste, Leser- oder Autorenfeld der Maske aufgeführt.
In der Maske sind weder Einschränkungen in der Leserzugriffsliste noch Leser- bzw. Autorenfelder enthalten.
-
Hi,
ich habe auch einige Zeit mit den und gegen die Tücken der Profildokumente "gekämpft". Irgendwann hatte ich die Nase voll und habe mit eine eigene Profildok-Klasse geschrieben. Ich ein bisschen aufwändiger zu implementieren, hat aber den Vorteil, das es funktioniert.
Schau mal hier:
http://www.free.dominoserver.de/computer/noteslibrary.nsf/d2d59a3d7fc73a2bc1256a6900638352/74e4b61d04ca824dc1256db20041582a!OpenDocument (http://www.free.dominoserver.de/computer/noteslibrary.nsf/d2d59a3d7fc73a2bc1256a6900638352/74e4b61d04ca824dc1256db20041582a!OpenDocument)
Vielleicht kannst du was damit anfangen.
Axel
-
... was auf jeden Fall hilft, ist in Profildokumenten immer Autorenfelder aufzunehmen, in denen eine Rolle erscheint, die alle diejenigen haben, die damit arbeiten, bzw. den vollen Notesnamen des Users.
Also sollte es eine Maske zum Profildokument geben, in der du mindestens ein Autorenfeld aufnimmst.
Bereits bestehende Dokumente ohne Autorenfeld werfen die Fehlermeldung, also müssen die Dokumente korrigiert werden...
... es gibt allerdings Tücken:
Der Besitzer des Profildokumentes sollte die Anwendung nicht geöffnet haben - um Speicherkonflikten vorzubeugen.
... dann entweder per Script die Autorenfelder setzen, wenn die alten Werte darin nicht verloren gehen sollen, oder das Profildokument einfach löschen. Das neue wird über die aktualisierte Maske erstellt und hat dann die notwendigen Berechtigungen.
... so habe ich das bei mir gelöst
ata
-
Vielen Dank für Eure Infos und Tipps.
Ich habe hier ja nur 2 Profildokumente, die lediglich dazu dienen, allgemeine Setup-Einstellungen zu machen.
Werde es jetzt aber auf ein normales Dokument auslagern, "da weiss man was man hat" :)
Matthias
-
Noch ein Nachtrag:
Habe in einer anderen DB das gleiche Problem mit Profildoks.
Dort hatte ich aber heute keine Lust mehr, das auch noch auf ein normales Dok umzustellen.
Daher hab ich den Tipp umgesetzt, mit einem Leserfeld zu arbeiten (mit einem Inhalt über eine Rolle, die alle Anwender einschließt) - und damit klappt es dann auch :-)
Matthias
-
... das Profildokument hat aus Sicht der Performance eindeutig Vorteile, da es permanent im Cache vorliegt.
ata
-
... und den nachteil, dass geänderte werte im profil-dok nicht sofort wirksam sind (böse erfahrung am eigenen leib) :P
-
... das gilt nur, wenn du das Dokument für dynamische Parameter nimmst, wie zum Beispiel Zähler etc...
... daher nimmt man DB-Profildokumente, die für alle User gelten für solche Zwecke nicht her, sondern nur für statische Parameter - welche DB liegt wo... etc
ata
-
Das ist genau der springende Punkt, man muss sich über die Funktionsweise des Cachings bewusst sein, dann hat man einen Anhaltspunkt, wann Profil und wann normales Setup-Dokument