Berechtigung Profiledokumente

[Jörg]

Hi,

ich brauche mal wieder eure Hilfe.

ich möchte mit folgenden Teil Code ein ProfileDokument beim
starten einer DB lade. Aber wenn ein User nun die DB startet erhält er immer die Meldung
das er keine Berechtigung für die Operation ("archive") hat.

Code

Sub Postopen(Source As Notesuidatabase)
	
	Dim workspace As New NotesUIWorkspace
	Dim session As New NotesSession
	
	Dim db As notesdatabase
	
	Dim docglobal As NotesDocument
	Dim docuser As NotesDocument
	Dim counter As Integer
	
	Set db = session.currentdatabase
	
	Set docuser=db.getprofileDocument("archive",session.UserName)
...........

wie kann ich einer Userrole die erlauben , das er ProfileDokumente anlegen darf???

Gruß JÖrg

[DAU-in]

ich nehme an, deine User haben Autorrechte?
Dann muss auf das Profil ein Autorenfeld, in dem sie (Name,/gruppe/Rolle) enthalten sind.

[m3]

Aus der Designer-Hilfe:

NotesDatabase GetProfileDocument ... looks for a profile document with the form name you specify, and creates a profile document if one does not already exist.

A user must have at least Author access in the ACL of a database to create a profile document that is available to all users.

[Jörg]

Auch das Autoren Feld in der Maske hat nicht
den gewünschten Erfolg gebracht.
Kann es evtl. auch daran liegen , das dieses Dokument nicht vorhanden ist??


Die User sind in der Zugriffskontrolle der DB nur als Leser angelegt.
Grund hier es sollen kein User einfach Dokumente hinzufügen , da die
DB nur durch eine Gruppe "x" gepfelgt werden soll.
Oder kann ich den Usern auch die Rechte sChreiber geben und dann bei Compose
eine entsprechende Abfrage hinzufügen?

[m3]

Wenn die User in der ACL "Leser" sind, helfen auch die Autoren-Felder nix. Du willst das Kapitel zur Sicherheit in der Notes-Hilfe nochmal studieren.

[koehlerbv]

Wenn die meisten User nur Leser sein sollen, aber trotzdem "ihr" ProfileDocument erstellen können sollen, solltest Du Dich mit dem Item "$PublicAccess" in der DesignerHelp beschäftigen - es gibt ein ausführliches Kapitel darüber.

Bernhard

PS: By the way - so funktioniert das übrigens auch mit Kalenderdokumenten im Mailfile.

[Jörg]

Hmm

(DAU Modus on)

ich traue nich dies kaum auszuschreiben, aber auch mit der Anleitung wie sie in
der Lotus Notes Hilfe für den $PublicAccess steht geht es auch nicht.

Die Felder wurden in der Maske so erstellt wie beschrieben, und klassefiziert.

Kommt der Felder evtl. doch aus einer anderen Richtung.......

GRuß Jörg
(DAU Modus off)

[DAU-in]

Wurde jetzt nur die Maske geändert, oder wurde das Feld auch in den bereits vorhandenen Dokumenten hinzugefügt, mit dem entsprechenden Wert?

Oder hast du jetzt nix geändert, sondern das war bereits so angelegt in der DB?

[Jörg]

Ich habe das Feld in der Maske hinzugefügt und dann
das Dokument auf den Server aktualisiert.

Aber ich weiß im Moment nicht weiter (bin halt dau ;-) )
da ich kein Profile Dokument auslesen kann.


Gruß ´Jörg

[pete_bla]

Hi Jörg,

Wenn Deine User in der ACL nur Leser sind,
nützt Dir für Profile auch das $PublicAccess nichts, solange sie nicht existieren.

Sie dürfen einfach keine Profile erstellen. (Dies muss wohl mit der Profileigenschaft zusammenhängen.)

Die Möglichkeiten würde ich Dir zur Abhilfe vorschlagen:

1. die Profile für die User im Voraus anlegen, ändern dürfen auch Leser, wenn du $PublicAccess="1" einträgst (worauf Bernhard raus wollte)

2. den Usern Autorenrechte geben.

3. normale Dokumente verwenden
(hier Feld:$PublicAccess="1", ACL "ÖffentlicheDokumente schreiben", Maske:"Verfügbar für Benutzer mit öffentlichem Zugriff")
dann gehts auch mit Leser.

Ich würde Dir aber zur "Autorenvariante" raten,
dann musst Du eventuell noch bei den Maskeneigenschaften einschränken, wer welche Dokumente erstellen darf, das dann am besten über Rollen.
Bei Autoren sind die vorhandenen Dokumente ja auch so lange vor Änderungen geschützt, wie Du sie nicht explizit durch Autoren-Felder für die Anwender freigibst. (-> siehe Adressbuch auf dem Server)

Gruss, Pete(r)

[koehlerbv]

Bei Autoren sind die vorhandenen Dokumente ja auch so lange vor Änderungen geschützt, wie Du sie nicht explizit durch Autoren-Felder für die Anwender freigibst. (-> siehe Adressbuch auf dem Server)

Nicht aber die Personendokumente dort - siehe Owner-Item, welches immer gesetzt wird.

Ansonsten stimme ich Dir zu. Wenn man wirklich die Leser beibehalten will (wofür ja einiges spricht und weniger Änderungen erforderlich sind), dann normale Dokumente statt Profildokumenten verwenden.

Bernhard

[DAU-in]

aber die Profile sind doch schon da, oder habe ich das Posting von Joerg falsch verstanden?

*das Dokument auf den Server aktualisiert*

[pete_bla]

Hi,

dann wundere ich mich wie sie reingekommen sind. (wurde die ACL geändert?)

Wenn Sie schon da sind ist ja alles wunderbar -

Dann einmal über alle Profile (->ProfileDocCollection)
$PublicAccess="1"
reinblasen
und die (vorhandene) User haben keinen Fehler mehr.

ABER:
Sie können eigentlich nicht da sein:
Der Fehler würde, wenn sie schon da wären, nicht bei der Zeile

Code

.GetProfileDocument(...)

sondern erst bei einem

Code

.save(...)

kommen!

Gruss, Pete(r)

[Jörg]

Nach einen Neustart des PC und einer erneuten Adressaktualisierung des
Dokumentes in der DB ist der Fehler weg.
Ich denke mal das hier noch etwas im Chache gelegen hat.

Danke Euch

Jörg

[ata]

... Profildokumente sind nicht unbedingt eine stabile Lösung - ich hatte versionsabhängig schon die tollsten Effekte und bin mittlerweile auf reguläre Dokumente übergegangen - da sehe ich eindeutig was ich habe...

Toni