Soft Delete - Hard Delete

[jr]

Hallo,

ich habe eine einfache Frage, finde aber keine Lösung:

Folgende Situation:

In einer Datenbank sollen Benutzer Dokumente per Soft Delete löschen können. Mit F9 verschwinden sie in die Löschansicht. Auf diese Ansicht sollen alle Zugriff haben, damit Sie ggf. die Dokumente wieder restaurieren können. Aber nur ein paar Benutzer sollen in dieser Ansicht den tatsächlichen Hard Delete (also das echte Löschen aus der Datenbank) ausführen können. Das Ganze soll nicht mit Buttons, sondern mit der ganz normalen ENTF-Taste durchgeführt werden.

Eigentlich ganz einfach, dachte ich. QueryDocumentDelete im Datenbankscript und den Namen der Löschansicht abgefragt. Pustekuchen - Bei einem Hard Delete geht Notes anscheinend nicht in den QueryDocumentDelete-Event rein!?!?!?

Hat jemand eine alternative Lösungsidee?

Wöre super, wenn mir da jemand helfen könnte.

Gruß,

JR

[eknori]

solltest du mit einer ROLLE und  Querydocumentdelete im DatenbankSript in den Griff bekommen.
radio GaGa; hast du ja schon getestet.

Warum machen Firmen solche Dinge: "Ich darf löschen; aber eigentlich darf ich das nichts")

[TMC]

Also diese Soft Deletions können sehr viel Ärger bereiten, ich vermeide diese eigentlich immer.

Besser IMHO:

Database-Script und "QuerydocumentDelete". Dort setzt Du dann ein Flag in ein Dokument (z.B. in ein Feld Deleted den Wert "1").
In Deinen Ansichten dann eine entsprechende Ansichtsauswahl, z.B. "SELECT Deleted = """
Dann eine "Papierkorb"-Ansicht mit Auswahlformel SELECT Deleted = "1".

Im QueryDocumentDelete aber eine Unterscheidung, z.B.

Select Case uiws.Currentview.Viewalias
Case "Papierkorb":
  'hier Dein Code der ausgeführt wird für Deinen Papierkorb
Case Else:
   'Code für alle "normalen" Ansichten


Damit nicht alle User endgültig löschen können, baust Du entweder eine entsprechende Abfrage im QueryDocumentDelete ein - oder sicherer:
Du entziehst den Usern beim Setzen des Lösch-Flags auch noch die Autorenrechte (also auf Dokumentenebene).

[jr]

Hallo,

danke für Eure Antworten. Das mit dem Lösch-Flag war meine erste Lösung, die ich so schon seit Jahren in meinen Datenbanken mit einer extra Papierkorb-Ansicht einsetze:

FIELD form := "Deleted " + Form

Für den Restore gibt's dann:

FIELD form := @Right(Form; " ")

Und dann noch eine entsprechende Form-Formula in der Papierkorbansicht, damit man die gelöschten Dokumente öffnen kann.

@Right(Form; " ")


Das Löschen im Papierkorb kann ich dann entweder mit einer Rolle oder noch einfacher über das "Dokumente löschen"-Flag in der ACL steuern.

Soweit so gut.  Das Ganze wir allerdings immer mit einem extra Löschen-Button aktiviert und nicht mit der ENTF-Taste. Die Anforderung vom Kunden war aber explizit, dass das Ganze über die ENTF-Taste, wie das "normale" Löschen passieren soll. Also erst mit einem x als zu löschend markiert und dann mit F9 ganz weg (in den Papierkorb, nicht aus der Datenbank).

Und da liegt auch das Problem: Wenn das Loschen-x erscheinen soll, kann ich mit QueryDocumentDelete nicht viel machen, weil die Benutzer ja das x wieder wegmachen können.

Also bin ich in den PostDocumentDelete gegangen, aber da ist es schon zu spät. Ich kann zwar noch auf die Dokumente zugreifen, aber eigentlich sind sie schon nicht mehr da. Ich bin dann auf die gloreiche Idee gekommen einfach schnell eine Kopie zu machen und die dann in den Papierkorb zu schieben. Da ich für Verknüpfungen mit einem eigenen Key-Konzept arbeite und nicht mit den DocumentUniqueId's macht es nichts, wenn die UnID eine andere ist.

Das ging auch eine ganze Weile ganz gut. Bis einer ein Dokument löschen wollte, für das er nur Lese-, aber keine Schreib-Rechte hat. Der Agent hat dann ganz toll eine Kopie des Dokuments in den Papierkorb gemacht. Und weil die Benutzer ja alles austesten, hat er natürlich gleich wieder einen Restore im Papierkorb gemacht. 

Diese Möglichkeit hatte ich übersehen, und jetzt brauche ich halt eine andere Lösung.

Gruß,

Joachim


P.S.:
Ich glaube als Entwickler kann man nie so verquer denken, wie ein Endanwender Es gibt praktisch nichts, was die nicht versuchen. War natürlich dumm von mir, diesen Fall nicht zu berücksichtigen, aber manche Bugs findet halt leider doch erst der Kunde...