QueryPaste verhindert auch nur das Einfügen.
Wenn die Leute replizieren müssen könntest du noch mit $KeepPrivate-Feld arbeiten. Das verhindert dann allerdings auch das Drucken
... und das Weiterleiten und die Möglichkeit, Teile aus einem Dokument in die Zwischenablage zu nehmen.
Wo ist dein Problem ? Was willst du verhindern ?
Gruß
Norbert
$KeepPrivate (im Dokument) und das Verbieten von Repliken / Kopien / Drucken ist sehr weitreichend. Das wird auch dem Administrator der DB auf die Füsse fallen.
Ich befürchte, Dir bleibt wirklich nichts weiter als die Nutzung des Events in allen Views / Folders.
Aber wie meine Vorredner tappe ich auch nach wie vor im Dunklen und gehe davon aus, dass Du das Kopieren und Einfügen von Dokumenten innerhalb einer DB verhindern willst.
Bernhard
PS: Die klare Formulierung einer Frage ist meist schon der halbe Weg zur Lösung.
Zitat
Nemesis schrieb:
(...)Kopien eines Dokumentes anlegen kann (Strg C / Strg V).
Zitat
koehlerbv schrieb:
gehe davon aus, dass Du das Kopieren und Einfügen von Dokumenten innerhalb einer DB verhindern willst.
So jedenfalls würde ich das verstehen.
Nemesis: du brauchst da gar keine Handstände mit Ansichts- oder Maskenevents machen. Agenten können getriggert werden auf "When documents are pasted"...
Mit einem derartigen Agent hast Du aber keine Rückkopplung mehr zum Anwender. Der wirft ein Dokument da hinein, und plötzlich ist es wieder weg ...
Bernhard
Naja, so eine freundliche MsgBox mit einem entsprechenden Hinweis wäre natürlich ein feiner Zug... 
Nette Diskussion über ein hausgemachtes Problem. Daher auch meine 5 Cents mal dazu, und (weils so schön ist) lasse ich mal den Besserwisser-Trainer raushängen:
Beispiel 1:
Ich gebe jemanden das Recht als Entwickler und wundere mich hinterher warum er sich munter Agenten erzeugt und überlege, wie ich das unterbinden kann.
Lösung für 1: ich gebe ihm halt das entsprechend niedrigere Recht.
(Das Thema war insbesondere bei älteren Notesinstallationen im Zusammenhang mit dem Out-Of-Office Agenten und dessen Aktivierung gern angefragt).
Beispiel 2:
Ich gebe jemanden das Recht als Editor und wundere mich, warum er munter Dokumente erzeugen kann (übrigens nicht nur per Copy und Paste, aber das nur nebenbei).
Lösung für 2: ich gebe ihm das für Nutzer eigentlich auch vorgesehene Recht als Autor. Der Rest ist easy per Programmierung lösbar. Haken beim Recht zum Dokumente erstellen fliegt weg und wenn er Dokumente im Sinne der Anwendung erzeugen muß tut der Knopf das über einen Hintergrundagenten, der mit anderen Rechten läuft und den Nutzer in ein Autorenfeld einträgt.
Alles andere ist "Bastelei". Selbst wenn hier mit supertollen Scripten an Stelle a) das Einfügen verhindert wird kann der Nutzer es über Stelle b). Ich werde jetzt hier nicht ausführlich werden, welche Wege es noch gibt, aber ein Beispiel als die simple Version: neuen Ordner anlegen ohne Gestaltung eines anderen zu übernehmen und schon geht da drin auch wieder das Einfügen (wenn ich Editor bin).
Der Editor ist nunmal das höchste Recht (!) auf Dokumentebene, das es innerhalb einer Datenbank überhaupt gibt. Also fangt bitte nicht an mit superaufwändigen Programmierungen Rechte neu abzubilden, die es schon lange gibt, nur weil der eigentliche Programmierer nicht in der Lage war/ist mit Leser- und Autorenfeldern vernünftig umzugehen!
Carsten
Die Lösung mit berechtigem Schreibagent ist natürlich ganz nett.
Einfacher gehts mit dem Agent
"When Documents are pasted" (Der im Deutschen falsch übersetzt wurde, da Passiv und Vergangenheit verwechselt wurden).
Dim s As New NotesSession
Call s.CurrentDatabase.UnprocessedDocuments.RemoveAll(True)
Also, streng genommen ist Carstens Vorgehensweise nicht "ganz nett", sondern absolut korrekt.
Der Agent, den wir beide ansprachen, ist eher als Workaround für den Fall gedacht, dass das DB- und Berechtigungsdesign zu wünschen übrig lässt. Dass es "einfacher" ist, hängt nur damit zusammen, dass man bestehende Fehler umschifft aber damit nicht verhindert, dass andere derzeit nicht absehbare Wecheselwirkungen auftreten (können). Von einem sinnigen Design, was ungleich zeitaufwendiger und schwieriger zu realisieren ist, gar nicht erst zu reden. Ob es unter diesen Gesichtspunkten auch langfristig die einfachere Variante war, sei einmal dahingestellt.
Merke: "einfach" ist "natürlich ganz nett", "richtig" ist aber immer besser!
Naja, sicherlich kann man das alles über Agenten realisieren und jede Funktion durch bessere, sicherer und komplexere Lösungen ersetzten.
Trotzdem kann auch ein Autor z.B. per Agent aus einer anderen Datenbank über das Backend Items ändern, die er über die Maske gar nicht ändern könnte und somit diverse Regeln aushebeln.
Um wirklich sicher zu gehen, dürfte wirklich nur der Server persistente Daten ablegen, Usereingaben müsste vorher entsprechend validiert werden.
ZitatTrotzdem kann auch ein Autor z.B. per Agent aus einer anderen Datenbank über das Backend Items ändern, die er über die Maske gar nicht ändern könnte und somit diverse Regeln aushebeln.
Das ist so nicht ganz korrekt. Ein Autor kann auch über Tricks nur Dokumente verändern, über die er auch mit Autorenfeldern berechtigt ist. Andere Dokumente kann er nicht manipulieren.
Anders sieht es natürlich aus, wenn der Programmierer hier eine eigene Berechtigungs-"Logik" mit Script in die Masken einaut.
Aber genau darauf bezog sich ja meine Aussage: wenn vernünftig (!) mit Autorenrechten und den entsprechenden Feldern arbeitet muß nirgendwo getrickst werden.
ZitatEinfacher gehts mit dem Agent
"When Documents are pasted" (Der im Deutschen falsch übersetzt wurde, da Passiv und Vergangenheit verwechselt wurden).
Dim s As New NotesSession
Call s.CurrentDatabase.UnprocessedDocuments.RemoveAll(True)
"Super" Idee, der Agent funktioniert aber nur, wenn der Nutzer sowohl Editor als auch Löschrechte hat.
Anderenfalls würde der Agent (z.B. bei Autorenrechten) nur dann arbeiten, wenn der Nutzer seine eigenen Dokumente dupliziert. Sobald er fremde Dokumente einfügt, für die er keine Autoren-Rechte hat, kommt eine Fehlermeldung und das betreffende Dokument bleibt in der Datenbank stehen.
Merke:
Die Kombination Editor + Löschrechte ist für eine saubere Multiuser-Anwendung nur dann sinnvoll, wenn das Einfügen, Löschen und Editieren beliebiger Einträge aus organisatorischer Sicht auch gewollt ist. In allen anderen Fällen ist mit Autorenrechten zu arbeiten.
Löschungen sind über Felder zu handhaben, die umgesetzt werden und die Dokumente ausblenden, damit lassen sie sich durch Verantwortliche später nachvollziehen, rückgängig machen oder eben durch einen Aufräumprozeß endgültig machen.
Der Hilfsagent zum Anlegen ist nur gegen den im Eingangspost erwähnten Mißbrauch nötig, um Nutzern das Einfügen fremder Dokumente zu verwehren, da das ausschließlich über das Erstellen-Recht handhabbar ist.
Carsten
Prinzipiell stimme ich Dir vollkommen zu, Carsten. Das ganze Getrickse, was man manchmal so sieht, hat man Sicherheit und ordnungsmeässem Ablauf kaum noch was zu tun.
Das mit dem Agent ist aber falsch: Der Agent läuft mit den Rechten der ID, mit dem er signiert wurde. Und das ist natürlich nicht der aktuelle Benutzer, der sich einen Spass mit dem Copy & Paste macht.
Bernhard
Bernhard: Das glaub ich nicht Tim 
Der Agent vom Typ "wenn Dokumente eingefügt ..." ist ein Frontend-Agent.
Und - bevor ich widerspreche teste ich natürlich, nur für den Fall dass ich falsch liege.
Und mein Test sagte mir gerade beim Versuch ein Dokument einzufügen: Notes Error - Sie sind zur Durchführung dieser Operation nicht berechtigt.
Er hat also ein Dokument eingefügt aber nicht gelöscht.
w.z.b.w.
Carsten
Ich hatte als User mir folgende Rechte eingeräumt:
Autor, Dokumente erstellen, aber _keine_ Löschrechte
Der Agent-Unterzeichner ist Manager mit allen Rechten, bei dem funktioniert der Agent natürlich, wenn ich den gleichen Test unter dessen ID durchführe.
Uips, da war ich aber mit meinen Gedanken gerade ganz woanders (neue und modifizierte Dokumente). Natürlich hast Du Recht, Carsten. Ich glaube, ich muss Dir spätestens in Gelsenkirchen ein Bier spendieren :roll:
Bernhard
Problem ist nur, dass es genug "gewachsene Lösungen" gibt, wo halt nun mal nicht sauber mit Berechtigungskonzepten umgegangen wird.
Editor+Löschen/Erstellen ist oftmals das Standard-Recht. Klar, kann man das mit mehreren Manntagen eine Applikations re-designen und migrieren und somit sicher machen.
Aber oftmals ist der "große Wurf" einfach nicht drin und kein Budget für eine Lösung von konzeptioneller Reinheit da.
Da ist ein einfacher Agent der seinen Zweck im Falle von Editor+Löschen/Erstellen grundsätzlich erfüllt, vielleicht die sinnvollere Lösung, oder ein continue = false in den QueryPaste-Events.
Merke: "einfach" ist "natürlich ganz nett", "richtig" ist auch immer besser, aber die beste Lösung ist in Hinsicht auf Zeit und Budget selten drin.
Was willst du jetzt eigentlich erreichen ?
Am Anfang ging es darum Das Kopieren zu verhindern und jetzt geht es ums Erstellen von Dokumenten ohne Dokumente erstellen Recht ?
