CanDeleteDocuments=True, trotzdem keine Berechtigung

[Moni]

Hallo an alle!

Folgendes Problem:
Ich habe eine DB in der die User eigentlich keine Dokumente löschen dürfen. Jetzt habe ich aber einen Agenten gestrickt, der nach vielen anderen Dingen den User in die ACL einträgt mit der Berechtigung Dokumente zu löschen, dann soll ein Dokument gelöscht werden und dann wird der User wieder aus der ACL gelöscht. Leider scheitert das ganze am löschen des Dokumentes.

Habe mal das Problem in folgendem Code zusammengefaßt:

Sub Initialize
   
On Error Goto ErrHandler
Dim session As New Notessession
Dim DB As NotesDatabase
Dim doc As NotesDocument
Dim collection As NotesDocumentCollection
   
Set DB = session.currentdatabase
Set collection =DB.unprocesseddocuments
Set doc = collection.GetFirstDocument
   
Do While Not (doc Is Nothing)
Dim acl As NotesACL
Dim entry As NotesACLEntry
Set acl = db.ACL
Set entry = New NotesACLEntry (acl, session.username, ACLLevel_Manager)
entry.CanDeleteDocuments = True
Call acl.save

If ( doc.Remove( True ) = False ) Then
Set doc=collection.GetNextDocument(doc)
   
Loop
   
ErrHandler:
Print " Error #" & Cstr(Err) & ": " & Error$ & " (" & Erl & ")"
End Sub


Das ich das gelöschte Dokument nachher nicht mehr als Parameter für die Collection verwenden kann ist mir klar. Ich verstehe nur nicht, warum er beim "Remove" immer in den ErrHandler springt, obwohl ich doch das Recht habe, Dokumente zu löschen. Ich erhalte folgende Ausgabe:

Error #4000: Notes error: Sie sind zur Durchführung dieser Operation nicht berechtigt (30)

Zieht das Recht nicht sofort?

[Semeaphoros]

Aus 2 Gründen geht das nicht:

a) die Rechte ziehen tatsächlich nicht sofort. Der Server cached die Rechte und es kann ziemlich lange dauern, dass der Access-Cache neu aufgebaut wird.

b) um eine ACL zu ändern, benötigt der Benutzer Manager-Rechte, sonst werden die Rechte nicht rausgeschrieben.

Heisst: da braucht es eine völlig andere Strategie, dafür gibt es ein Datenbank-Event "QueryDocumentDelete", damit lässt sich das Löschen dann auf ganz bestimmte Fälle begrenzen.

[Axel]

Hi,

meines Wissens zieht eine Berechtigungsänderung in der ACL erst nach der Neuanmeldung des Users. Unter Umständen ist es manchmal sogar notwendig, den Client neu zu starten.

Frage:     Wo liegt der Sinn den User in die ACL einzutragen wenn er ein Dokument löschen will und dann wieder zu löschen? Trage den oder die User doch gleich fest in die ACL ein. Das spart jede Menge Ärger?

Axel

[koehlerbv]

Hallo, Moni,

ACL-Änderungen werden erst nach Neuanmeldung durch den Client wirksam - wie Semeaphoros und Axel schon geschrieben haben. Von den erforderlichen Manager-Rechten für ACL-Änderungen wollen wir mal gar nicht reden ;-)

Ein unkonventioneller Vorschlag: Lass Deine User doch Dokumente "löschen", aber nicht wirklich ;-)
- Stell Deine Ansichten um, daß sie nur die Forms Deiner Wahl anzeigen
- Wenn ein User "löschen" will (via Script: QueryDocumentDelete, mit @functions geht das so nicht, dann muss Du einen "Lösch"-Button einbauen), änderst Du das "Form"-Item um auf "Deleted" + Form
- In einer eigenen Ansicht (mit der Auswahl @Left (Form; 7) != "Deleted) siehst Du nun die "gelöschten Doks und kannst sie bei Fehlverhalten der User über eine entsprechende Aktion wieder restaurieren.

HTH,
Bernhard

[Moni]

Erstmal danke für eure schnelle Hilfe.

@Axel
Der Sinn ist leider super kompliziert. Ich habe eine DB, in der die Anwender nur bestimmte Dokumente löschen dürfen. Daher haben Sie in der ACL nicht grundsätzlich das Recht zum löschen, sondern ich habe einen Button eingebaut, über den die User löschen dürfen. (QueryDocumentDelete) ;-)

Seit einiger Zeit habe ich allerdings das Problem, dass beim Lauf eines Agenten beim Call doc.save(true,true) der Fehler auftaucht "Element des Dokumentes nicht gefunden". Den Fehler habe ich mit allen Mitteln versucht zu beheben, aber keine Chance. (Absolut kuriose Sache, passiert nämlich nicht bei allen Anwendern)
Jetzt versuche ich das Speichern zu umgehen, indem ich in der DB eine Kopie des Dokumentes anlege, da ich die Kopie nicht extra speichern muß und muß das alte Dokument löschen, da auf keinen Fall zwei gleiche Dokumente drin sein dürfen.
Der Agent wird vom Benutzer auf dem Client gestartet und daher benötigt er für einen kurzen Moment das Recht, Dokumente zu löschen.

Tja, muß mir aber wohl etwas anderes einfallen lassen. Wäre ja auch zu einfach gewesen.  

[Moni]

@koehlerbv
Leider auch nicht möglich, da es eigentlich gar nicht ums Löschen geht.
Die User übertragen aus einer DB Fehlzeiten an das SAP-System. Je nachdem, ob erfolgreich übertragen oder nicht, ändert sich der Status des Docs und diese Änderungen müssen dann gespeichert werden, tun sie aber leider seit dem Notes5 Client nicht mehr bei jedem.
Wie oben beschrieben, daher der Versuch das Speichern zu umgehen.

Aber trotzdem vielen Dank für deine Hilfe!

[Semeaphoros]

Moni: da steht die Strategie irgendwie schief in der Landschaft

[ata]

... ich würde es auch über Löschmarkierungen machen, und die Dokumente - wenn markiert - nicht mehr in den "normalen" Ansichten anzeigen. So hättest du auch die Möglichkeit einer "Papierkorbfunktion"...

ata

[Axel]

Hi,

lassen sich diese "bestimmten Dokumente" an igendwas eindeutig indentifizieren, Maskennamen oder bestimmter Feldinhalt oder so was?

Dann könntest du in QuerydocumentDelete eine Abfrage einbauen, wenn bestimmtes Dokument, dann löschen, sonst nicht.

Axel

[koehlerbv]

und diese Änderungen müssen dann gespeichert werden, tun sie aber leider seit dem Notes5 Client nicht mehr bei jedem

Hier ist doch der Ansatz völlig falsch. Ihr habt schlichtweg einen Programmfehler, und der muss gefunden werden, anstatt derartig krude Konstrukte zu bauen.
Wenn Ihr R5 korrekt sagt "speichere", dann speichert R5 auch, und zwar jedes Mal.

Bernhard

[Moni]

Ich weiß, dass es eigentlich nichts schlimmeres gibt, als einen Fehler nicht zu beheben und statt-dessen einen Workaround zu basteln.
Aber ich weiß einfach nicht mehr weiter! Wir haben ganze zwei Wochen nach der Fehlerursache gesucht und versucht, den Fehler zu beheben. Wir haben sogar eine komplett neue Version der Anwendung eingespielt mit einer komplett neuen SAP-Schnittstelle und der Fehler tritt weiterhin auf.

Der Agent tut nichts weiter als aus dem gewählten Dokument Werte auszulesen, diese für SAP umzuwandeln, in SAP eine neue Fehlzeit anzulegen und ändert dann den Dokumentenstatus (Text-feld), je nachdem, ob erfolgreich oder nicht. Dann speichert er das Dokument, manchmal.

Der Code kann an sich nicht falsch sein, da es bei der Hälfte der Anwender funktioniert. Am Dokument kann es auch nicht liegen, denn wenn zwei Anwender das gleiche Dokument übertragen, klappt es bei einem und bei dem anderen nicht.
An den Berechtigungen kann es auch nicht liegen, da ich Managerrechte habe und bei mir das Problem z.B. auch auftritt.

Es passiert allerdings nur, wenn ich den Agenten aus persönlichen Ansichten aufrufe. Desktop5.dsk löschen hat aber leider auch nicht geholfen.

Montag sehen wir weiter, jetzt ist erstmal endlich Feierabend!

[ata]

... habt ihr Autorenrechte integriert?

ata

[Moni]

Es geschehen noch Zeichen und Wunder!

Das Problem ist doch bereits bei Lotus bekannt und steht sogar in der Knowledgebase. Ich habe mich zu sehr auf eine andere Übersetzung des Fehlers versteift.

Dokument 169633 "Back-End Save Can Cause Error When Called From "Shared Private on First Use" View Stored in Desktop"

Antwort von Lotus: Unter 5.0.11 ist dieser Fehler schon häufiger aufgetreten, sie selber konnten diesen aber noch nicht nachstellen und somit auch nicht beheben.

In den Versionen 5.0.5 und 5.0.10 ist dieser Fehler wohl bisher noch nicht aufgetreten.

Gruß,
 Moni

[koehlerbv]

Ich gratuliere zu dieser (erfolgreichen) Detektivarbeit !
Das Knowledgebase-Dokument kommt bei mir gleich in den Giftschrank unter die Rubrik "Vorsicht vor dem Hunde" ;-)
Damit mir nicht mal das Gleiche passiert ...

Dankeschön,
Bernhard