Das Notes Forum
Domino 9 und frühere Versionen => Entwicklung => Thema gestartet von: notesnewbie am 29.09.03 - 09:05:34
-
Hallo,
ich hab da ein Problem ;D
Ich möchte über ein LS-Script eine Rolle in einer Anwendung ändern
um einem User Schreibrechte auf ein Dokument zu geben. Nach dem Schreiben möchte ich ihm die Rolle wieder entziehen. So weit so gut.
Wenn ich das LS mit meinem User durchführen funktioniert es auch,
aber wenn es der User macht sagt er das er keine Berechtigung hat.
Ich vermute das es daran liegt das der User kein Manager der DB ist.
Meine Frage ist also wie kann ich das Programm sozusagen mit meinem Profil laufen lassen. Ich dachte bisher immer das wenn ich das LS-Script speichere es mit meiner ID signiert und damit auch meine Berechtigungsstufe hat. Scheint aber nicht so zu sein.
Ich hoffe das jemand von euch mir einen Tip geben kann.
Danke
NoteNewbie
-
Genau.
Das Scirpt läuft auf dem SERVER mit Deinen Rechten. Auf dem CLIENT (also wenns vom User aufgerufen wird) läuft es mit den Rechten des Users. In R5 gibt es meines Wissens dafür keine Lösung.
Geht es ums Erstellen von neuen Dokumenten? Oder gehts ums Editieren? Beim Erstellen ist die Sache relativ einfach: Der User das Author-Feld wird erst beim Speichern wirksam. Wichtig ist hier, dass der User das Formular benutzen darf. Das ist in den Formulareigenschaften einstellbar.
-
Hi @Semeaphoros,
es geht um das ändern eines Dokumentes. Ich möchte das der User
im Backend ein Dok editiert für das er normalerweise keine Rechte hat. Weisst Du vielleicht eine Lösung ?
NotesNewbie
-
In R5 geht das nicht direkt. In ND6 denke ich, gäbe es eine Möglichkeit.
Etwas kompliziert aber vielleicht ein Workaround: Das Dokument kopieren in ein temp-Dokument, die Kopie editieren (ich denke mal, dass man da das Autor-Feld umgehen kann, sonst müsste man die Items kopieren, exkl. das Autor-Feld) und dann per Agent, der auf geänderte und neue Dokumente reagiert, das Originaldokument auf dem Server updaten. Da gelten dann Deine Zugriffsrechte. Nachteil: Falls man den Bearbeiter nachführen will, muss man das in dieser Konstruktion schon selber machen, das $UpdatetBy wird dann natürlich immer auf den Unterschreiber des Agenten gesetzt
-
Hi @Semeaphoros,
danke für deine Hilfe. Ich denke ich muss mir dann ne andere Lösung überlegen.
NotesNewbie
-
Das denke ich auch. Mein "Workaround" ermöglicht ja nur indirekt, was Du da ursprünglich wolltest. Normalerweise lassen sich solche Workarounds durch einen anderen Logikaufbau vermeiden.
Ein Ansatz wäre eventuell, das Verwenden von Antwortdokumenten, was gleichzeitig auch eine History ermöglichen könnte (Antwortdokument und Uebernahme der Werte des Originaldokumentes, diese Funktionalität gibts ja). Beim genauen Ueberlegen könnte man mit so einer Konstruktion den von Dir gewünschten Effekt ungefähr erreichen, hat dann aber die alten Dokumente rumliegen, die dann irgendwie entsorgt werden müssen.