Nutzereinstellungen auslesen

[dabjoern]

Hallo auch,
ich suche nach einer eleganten Lösung für folgendes Problem: Über einen Button kann der Nutzer ein Formular öffnen, in dem er persönliche Einstellungen vornimmt. So soll er bspw. benennen, ob er Anfänger, Fortgeschrittener oder Pro ist. Die getroffenen Einstellungen möchte ich datenbankweit abrufen können. Öffnet der jeweilige Nutzer ein anderes Form, möchte ich gewisse Absätze je nach "User Level" (Anfänger,...) verbergen.

Bisher habe ich das Formular erzeugt, in dem der Nutzer seine Angaben trifft. Wie sollte ich eleganterweise vorgehen? Sollte ich eine View anlegen, in der ich Username und "User Level" abspeichere und dann in den jeweiligen Formularen diese View abfrage und so das Level in einem hidden field bereitstelle?

Bin für jede Hilfe und Anregung dankbar.
Gruß
Björn

[RonMat]

Ein Ansatz wäre die Einträge in der Notes.ini des Users zu speichern und dann gegebenenfalls an dieser Stelle die Werte auslesen.

[dabjoern]

Sehe ich das richtig, dass man das mit diesen Environment Variabeln macht? Hatte schonmal hier im Forum rumgesucht und bin auch in der Designer Hilfe auf diese ganze Sache gestoßen.

Kurze Verständnisfrage: Es gibt doch nur pro Client Installation (also pro Workstation) eine notes.ini. D.h. arbeiten 2 oder mehr User an einer Workstation, so greifen sie beide auf die gleiche notes.ini zu. Oder sehe ich das falsch? 
Gruß
Björn

[TMC]

Hmm, notes.ini würde ich vermeiden, ich denke hier kann man mit Profildokumenten arbeiten.

In einem Dokument nutzt Du dann Hide/When-Formeln mit @GetProfileField.

Bezüglich Hide/When: siehe AtNotes Best Practices: Verbergen-Wenn (Hide-When) - Formeln

[TMC]

Kurze Verständnisfrage: Es gibt doch nur pro Client Installation (also pro Workstation) eine notes.ini. D.h. arbeiten 2 oder mehr User an einer Workstation, so greifen sie beide auf die gleiche notes.ini zu. Oder sehe ich das falsch? 

Du kannst auf einem Rechner mit mehreren notes.ini's arbeiten, z.B. indem Du Notes wie folgt startest:
C:\Programme\Notes\nlnotes.exe =X:\USER\notes.ini

Wird während einer Session die user.id gewechselt, so wird auf dieselbe notes.ini zugegriffen. AFAIK ist also nur während des Client-Starts hier eine Beeinflussung möglich.

Ich persönlich vermeide die notes.ini soweit es irgendwie geht.

[dabjoern]

Danke TMC,
deinen Beitrag zu hide-when habe ich mir schon zu Gemüte geführt.  Super, solche Tuts sind unheimlich wertvoll. Handelt es sich bei solchen Profildokumenten um etwas spezielles oder nennen wir die nur so aufgrund ihrer Funktionalität? Ich werde mal die Designer Hilfe bemühen...
Gruß
Björn

[RonMat]

Klar, ProfilDoc ist o.k. Mit Einträgen in der Notes.ini hatte ich bisher auch noch keine Probleme

[TMC]

Björn, genau, am besten liest Du das mal nach (Designerhilfe oder in einem Buch).

Grundsätzlich sind "Profildokumente" eine Funktionalität, die Notes schon mitliefert (inkl. Formeln mit denen Du diese ausliest). Ich denke für Deinen Zweck sind diese ziemlich ideal. Du kannst diese auch pro User (anhand @Username) anlegen.
Ein Nachteil kann sein, wenn sich dort Inhalte häufig ändern, weil Notes diese cached. Wird aber bei Dir nicht der Fall sein (so oft wird sich der Status "Anfänger, Fortgeschrittener etc." nicht ändern).

[koehlerbv]

Obicht - das Nutzerprofil soll datenbankübergreifend ausgelesen werden. Profildokumente eignen sich dafür nicht, wenn Formelsprache verwendet werden soll oder muss. Dies würde also auch Spaltenformeln betreffen, insofern dies erforderlich wäre. Hier gilt aber gleiches für Environment-Variablen.

Bernhard

[TMC]

Obicht - das Nutzerprofil soll datenbankübergreifend ausgelesen werden.

Wo steht das, Bernhard, kann gut sein dass ich da was übersehen habe, aber:

Die getroffenen Einstellungen möchte ich datenbankweit abrufen können.

Wenn übergreifend (also auslesen von DB2 aus DB1): dann hast Du natürlich Recht, dann eignen sich Profildokumente eher nicht.

[koehlerbv]

Genau das von Dir gefundene Zitat meinte ich, Matthias.

Bernhard

[TMC]

Datenbankweit heißt doch "datenbankweit", also nur diese Datenbank betreffend, oder?
Sonst würde es doch "datenbankübergreifend" oder "systemweit" heißen 

Matthias

[Semeaphoros]

Jo, Datenbankweit ist eindeutig innerhalb derselben Datenbank, nicht übergreifend.

[koehlerbv]

Warten wir die Antwort des Fragenden ab, aber mit hoher Wahrscheinlichkeit stimmt Eure Vermutung. Wenn dann auch nur noch Masken betroffen sind, um diese Profile auszuwerten, ist das ProfileDoc erste Wahl und die NOTES.INI (wie oft) ein NoNo.

Bernhard

[dabjoern]

Hallo auch,
wow bin überwältigt von der Response Zeit und Beteiligung in diesem Forum. Vielen Dank an Euch.

Die Vermutung stimmt. Ich möchte, dass die Werte nur innerhalb der einen Datenbank zur Verfügung stehen und nicht systemweit. Ich hoffe, dass sind die richtigen Begriffe zur Unterscheidung: datenbankweit (nur in der einen DB) versus datenbankübergreifend. Werde mich jetzt also in diese Profildokumente reinarbeiten. Vielen Dank.
Gruß
Björn

[Semeaphoros]

Björn, die Begriffe hast Du richtig verwendet.

[dabjoern]

Ich habe jetzt gemerkt, dass wenn ich einen neuen Nutzer für die Datenbank zulasse, und er sie öffnet, kein neues Profildokument für ihn automatisch angelegt wird. Drückt der Nutzer auf meinen Button mit der nachfolgenden Formel wird kein neues Profildokument (entgegen der Designer Hilfe) angelegt:

Code

@Command([EditProfileDocument];"UserProfile";@UserName)

Statt dessen kommt die Meldung:

You are not authorized to perform that operation.

Der Nutzer hat Autorenrechte für die Datenbank.

In der Designerhilfe steht für obige Formel:

Code

Creates a new or opens an existing profile document in Edit mode. 
Note  This @command is new with Release 6.
Syntax
@Command( [EditProfileDocument] ; formname; uniqueKey )

Sollte ich unter Other | Database Resources ein Skript hinterlegen, welches automatisch ein Profildokument für den jeweiligen Nutzer anlegt? Im persönlichen Adressbuch ist ja so ein ähnliches Skript:

Code

	Set profile=db.GetProfileDocument("UserProfile")
	If profile.Owner(0)="" Then
		Call CreateDefaultUserProfile
	End If
	Exit Sub

Code

Sub CreateDefaultUserProfile	
	On Error Goto ErrorRoutine
	'the global variable "profile" is a profile document already
	'we need to add the fields to it
	
	Call profile.ReplaceItemValue("Owner", session.Username)
	
	Call profile.ReplaceItemValue("Form", "UserProfile")
	Call profile.ComputeWithForm(False, False)
	
	Call profile.Save(True,True,True)
	Exit Sub
	
ErrorRoutine:
	Messagebox "CreateDefaultProf: " & Error$ & " " & Erl
	Exit Sub
End Sub

Was denkt ihr hierzu? Danke für jede Hilfe.

Grüße
Björn

[dabjoern]

Also ich hab jetzt noch ein wenig rumprobiert und mal den Code wieder aus Database Resources rausgenommen.

Außerdem habe ich dem User zusätzlich zu seinen Rechten erlaubt neue Dokumente zu erstellen. Also habe ich in der ACL "Create Documents" aktiviert.

Nun geht es. Hat das irgendwelche Nachteile? Gibt es hier Sicherheitsbedenken?

Grüße
Björn