Leser-/Autoren- Berechtigung VOR erstem speichern

[Tode]

Tach. Ich entwickle gerade eine Applikation mit konfigurierbaren Berechtigungen pro Kategorie.

Das heisst: Für eine Kategorie sind in einem Konfig- Dokument Leser- und Autoren- Felder hinterlegt. Wird ein Dokument mit dieser Kategorie erstellt, dann liest es dieses Konfig- Dokument aus und setzt die entsprechenden Berechtigungen.

Jetzt habe ich folgendes Problem: Wählt ein User eine Kategorie aus, für die er nicht im Konfig- Dokument steht, dann kann er das Dokument genau einmal speichern. Danach sieht er es nicht mehr (weil er ja nicht in den Konfig- Dokumenten sieht.

Wunsch: Ein User soll keine Dokumente erstellen / speichern können, für die er später keine Berechtigung haben wird.

Problem 1: die besagten Feldtypen (leser- felder / autoren- felder ) ziehen erst NACH dem ersten speichern.

Problem 2: in den Konfigurationsdokumenten sind ggf. Gruppen / Rollen hinterlegt, so dass ein einfaches Abfragen auf den Namen auch nciht möglich ist...

Mein momentaner Ansatz: über UserNamesList die Liste der berechtigten und die User- Berechtigungen abgleichen und bei übereinstimmung zulassen (Nachteil: Funktioniert nur bei Server- Verbindung).

Hat jemand nen besseren Ansatz ?
Thanx
Tode

[Axel]

Du kannst dem ganzen aus dem Wege gehen, in dem du dem User nur die Kategorien anbietest, für die er auch Rechte hat.

Aus dem Bauch heraus wäre das mit einer Ansicht, die in der ersten Spalte nach den Rollen kategorisiert ist und in der zweiten Spalte alle Kategorien zur jeweiligen Rolle anzeigt.


Axel

[Tode]

das wäre gangbar, wenn es sich nur um rollen handeln würde... aber die Berechtigungen werden von den Benutzern dynamisch über Rollen, Gruppen, Einzelpersonen vergeben...

trotzdem danke für die Hilfe.

Tode

[Glombi]

Haben die User Autorenrecht?
Falls ja und der User steht weder namentlich noch via Rolle oder Gruppe im Autorenfeld, dann kann er das Dokument nicht speichern.

Diesen Fehlercode müsstest Du im Script abfangen und eine entsprechende Meldung geben.

Andreas

[Tode]

das ist leider falsch @Glombi...

Autorenfelder ziehen leider erst NACH dem ersten speichern:

Erstell probeweise eine Maske mit 2 Feldern:

1 Autorenfeld, berechnet, wert "[nobody]"
1 Text- Feld für eingaben.

Gib einem Dummy- User nur autorenrechte auf die DB und lass ihn ein Dokument erstellen:
Er kann das DOkument EINMAL abspeichern, erst beim zweiten versuch bekommt er die Meldung über die Rechte...

Ist zwar dumm, ist aber so.....
ich habs jetzt über @UserNamesList *= Berechtigungen gemacht. Da die Datenbank nicht lokal mitgenommen wird, ist das ne Lösung aber schön ist das nicht....

Gruß
Tode

[Glombi]

Ich dachte eher daran, das Dokument im Backend zu speichern, nicht im Frontend. Und da sollte es auch beim ersten Speichern nicht gehen.

Das doc.Save(...) ins QuerySave einbauen und den Error abfangen.

Andreas

[Glombi]

Ich habe es eben ausprobiert - Notes reagiert mal wieder unerwartet. Ob es schon immer so war, wage ich zu bezweifeln:
Also trotz
Continue = false
im Error Handling
wird ein Dokument erstellt, aber ohne das Feld "Form".
Es kommt aber die Meldung, dass der User nicht als zulässiger Autor aufgeführt ist.

Also: Auch keine so tolle Lösung.

Andreas

[Tode]

hab's grade auch probiert...

Die Fehlermeldung, dass man nicht berechtigt ist, kommt (genau wie ohne querysave auch) beim zweiten speichern (das doc.Save läuft ohne Fehler durch, und wenn dann das querysave versucht zu speichern, dann kommt der Fehler...

Man könnte das jetzt so probieren:

wenn neu:

doc.Save( true , True )
doc.Save( True, True )

error beim zweiten save abfangen und dann das Document über doc.Remove( ) wieder löschen und continue = false setzen... aber schön ist was anderes....

Danke Dir trotzdem für die Mühe...

Wobei ich grundsätzlich davor zurückschrecken würde, im Querysave ein doc.save zu machen. ich hätte auch ehrlich erwartet einen "nested- event" - Fehler zu bekommen....

Thanx
Tode

[koehlerbv]

Wobei ich grundsätzlich davor zurückschrecken würde, im Querysave ein doc.save zu machen. ich hätte auch ehrlich erwartet einen "nested- event" - Fehler zu bekommen....

Warum solltet das zu einem nested event führen? QuerySave ist FrontEnd (und ergibt auch ein nested event, wenn man dort ein NotesUIDocument.Save probiert), NotesDocument.Save jedoch Backend.

Warum hast Du eigentlich Befürchtungen wegen dem Erkennen der UserNamesList, wenn Du mit einer lokalen Replik arbeitest? Wenn Du Rollen verwendest, brauchst Du doch sowieso eine konsistente ACL.

Bernhard

[diali]

warum erstellst du in den Konfig-Dokumenten nicht Leserfelder und trägst dort nur die Rollen, Gruppen und User ein, die Dokumente für diese Kategorie erstellen dürfen. Dadurch werden den Usern beim DBColumn nur die Einträge angeboten, für die der User Dokumente erstellen darf.

[Tode]

@koehlerbv: Dass sich mit den lokalen Datenbanken die Katze selbst in den Schwanz beisst habe ich inzwischen selbst gemerkt, nicht wegen der Rollen (die sich dank konsitenter ACL ja auch lokal nutzen lassen) sondern wegen der Gruppen in den Konfigurationsdokumenten, die ja lokal auch nicht aufgelöst werden können...

Also vergessen wir das Thema einfach.. und wegen der nested events habe ich nicht aufgepasst (Frontend / Backend). Danke für den Hinweis.

@diali: das ist leider nicht so einfach... ich poste mal einen Screenshot, dann wird's vielleicht klarer...

es sind drei Dokumenttypen beteiligt:
1. Kategorie- Dokumente, in denen die verfügbaren kategorien angelegt werden. (Kategorien)
2. Arbeitsdokumente, die diesen Kategorien über dbcolumns und dblookups diesen Kategorien zugewiesen werden (Dokumente)
3. Berechtigungs- Dokumente, die einzelnen Kategorien Berechtigungen zuweisen (Berechtigungen)

Hintergrund: Es handelt sich um eine Infothek, die eine Dateisystem- Verzeichnisstruktur ablöst, und die von NT bekannten Berechtigungen sollten ins Notes übernommen werden...

Es kann nun deshalb sein, dass der User Kategorien sieht (weil er leser ist) aber keine Dokumente in dieser Kategorie erstellen kann (weil er keine Schreibrechte hat).
Deshalb fällt Deine Lösung leider flach.