Zur Durchführung dieser Operation nicht berechtigt

[jo@chim]

Diverse Dokumente in einer DB, die von einem speziellen Anwender erstellt wurden, lassen sich nicht mehr weiter speichern, weder von ihm selbst noch von anderen - Fehlermeldung:

Sie sind zur Durchführung dieser Operation nicht berechtigt

Der Anwender wird als Ersteller in eines der Autorenfelder des Dokuments geschrieben und hat auch Bearbeiterrechte (ebenso wie verschiedene andere Rollen und berechtigte Autoren).
Wenn ich (mit Zugriffsrecht Manager) versuche, die Dokumente zu speichern, tritt der Fehler ebenfalls auf.
Auf Ansichtsebene, wenn ich einen @Command([ToolsRefreshSelectedDocs]) über das Dokument laufen lasse, erscheint eine Fehlermeldung in der Form

Noch zu verarbeitende Dokumente:0, ID des Dokuments, das den Fehler verursacht = 1927E

in der Statuszeile.
Der Fehler tritt in unregelmässigen Abständen und nur bei diesem Anwender (soweit ich das bisher überblicke) auf. Ich habe mir sein Personendokument in der names.nsf angesehen - kann keine "Besonderheiten" entdecken.
  Any hints?

[klaussal]

Die Funktionalität von Autorenfeld und Autorenzugriff in der Datenbank-ACL stehen in engem Zusammenhang. Wenn Sie einem Benutzer Autorenzugriff in der ACL zuweisen, kann dieser Benutzer in der Datenbank Dokumente lesen. Er kann jedoch nicht einmal die eigenen Dokumente bearbeiten. Wenn Sie den Benutzer in ein Autorenfeld aufnehmen, kann er Dokumente in der Datenbank bearbeiten.

Oder gibt's da was im Querysave ?

Vielleicht hat das Doc auch einen Schlag weg...

[jo@chim]

Dass der Benutzer in einem der Autorenfelder steht und auch Bearbeiterrechte hat, habe ich doch geschrieben.
Mir ist das Konzept der Autorenfelder bzw. des Autorenzugriffs insofern geläufig.
Im QuerySave schreibt mir ein Script lediglich einige History-Werte in ein Feld - ich habe das als Fehlerquelle aber ausgeschlossen (erst mal auskommentiert).
Wenn es nur ein einziges Doc wäre, das "einen Schlag weg" hätte, wärs auch nicht wirklich ein Problem. Es handelt sich aber um mehrere Dokumente und der Fehler tritt nicht das erste Mal auf ...

[klaussal]

"Bearbeiterrechte" kenne ich so nicht. Ich halte mich da an die Begrifflichkeiten der ACL. Das stiftet dann auch keine Verwirrung.

Wenn der Fehler nur ab und an auftritt, ist es fast unmöglich herauszufinden, an was es liegt.

[jo@chim]

Bearbeiterrechte

stammt aus der Terminologie der Anwendung - sorry, falls ich Dich damit verwirrt habe: der Anwender erhält über eine Prüfung

Code

If uidoc.editmode = False Then ...

eine Meldung, wenn er das Dokument nicht bearbeiten kann ("Sie haben keine Bearbeiterrechte"). Das Editmode gibt im gegebenen Fall aber True zurück. Es handelt sich also bei dem Problem sicher nicht um eines der Autorenrechte an dem Dokument. Auch deshalb nicht, im Übrigen, weil der Speicher-Fehler ja auch bei Zugriff mit Manager-Rechten auftritt, wie ich schon beschrieben habe.
Welche Ursachen könnten sonst noch in Frage kommen?

[Hive]

schon die Rollen in der ACL überprüft??

KAI

[jo@chim]

schon die Rollen in der ACL überprüft??

Ja. (Hab ich doch geschrieben)

[klaussal]

Debugger mitlaufen lassen und sehen, wo das Teil Mucken macht.

Ansonsten ist das hier eine Stocherei im Nebel.

[sloe]

Schau Dir mal Deine Reader-Felder an.

[jo@chim]

@klauss: wenn ich mir das nicht schon im Debugger angesehen hätte, würde ich mich schämen, es hier als Problem zu posten 

Die Fehlermeldung tritt bei, wie sich jetzt herausgestellt hat, allen Dokumenten eines einzelnen Anwenders unabhängig von jeglichem LS-Code, jeder Zugriffsebene oder Rolle in der ACL auf.

@sloe: In dieser Anwendung arbeite ich nicht mit Readers-Feldern. Inwiefern könnten diese Speicherprobleme verursachen?

[sloe]

@ jo@chim
Kann tatäschlich passieren. Man geht in den Edit-Mode, führt ein paar Aktionen aus, die Reader-Felder auf einen netten, anderen Wert setzen und beim zweiten Speichern:
"Sie sind zur Durchführung dieser..."
Da Readerfelder auch bei Manager-Rechten greifen...
Aber wenn Du keine R-Felder hast, wird es eklig.
Schmeiß das Dok doch mal in den docviewer von Mayflower, vielleicht fällt Dir dann was auf:
http://www.maysoft.com/web3.nsf/page/products-document_viewer-overview

[datenbanken24]

Ich schreibe nur mal kurz einen Hinweis,
weil wir seit einigen Wochen an einem ähnlichen Problem sitzen.

Ob es ansatzweise mit Deinem Problem zu tun hat, kannst Du schnell prüfen.
Aber vorweg - eine Lösung habe ich noch nicht dafür...

Auch so eine Sache, die eigentlich gar nicht sein KANN,
wo wir alles schon durchsucht haben - und einfach nix finden:

Ein ganz bestimmter Benutzer (Author) speichert Dokumente und haut dabei in vier immer gleiche Felder,
einen PROTECTED Feldschutz rein. Diese vier Felder haben dann die Feldeigenschaft "PROTECTED",
(siehe Screenshot). Nur bei diesem Benutzer - bei anderen passiert das nie.

Der User kann nach dem Speichern das Dokument nicht mehr bearbeiten - und kann es nur noch einmal zum Server replizieren. Wenn der PROTECTED Schutz bei diesem Dokument repliziert ist, können die anderen User (auch Authoren, aber alle im Authoren-Feld) dieses Dokument nicht mehr bearbeiten oder schreibend replizieren. Das ist auch logisch, weil ein Author ein Dokument nicht mehr bearbeiten kann, wenn ein Feld darin die Feld-Eigenschaft "PROTECTED" hat und er nur Author ist - AUCH wenn er in einem Authorenfeld steht.

Es gibt (in unserem Fall) KEINE einzige Zeile Code in der Anwendung, die ein Feld programmtechnisch protected, das ganze Wort "PROTECTED" oder "IsProtected=" kommt nicht ein einziges mal im gesamten Sourcecode der Datenbank vor - das ist sicher, dafür gibt es Tools. Außerdem ist die Anwendung selbst geschrieben und wir nutzen keine PROTECTED Feldeigenschaft. Und natürlich haben die Felder in der Maske auch nicht die Eigenschaft "Must have at least Editor access to use".
Der Anwender hat auch keinen PDA-Abgleich oder kein Dritt-Tool, was er über die Anwendung jagt.

Im Gegensatz zu Deinem Problem kann aber jeder mit mindestens Editor-Access das Dokument weiter bearbeiten.


Prüfe doch einfach mal über die Property-Box, ob es Felder in Deinen betreffenden Dokumenten gibt,
die die FELD-Eigenschaft / Feld-Flag: "PROTECTED" haben.
Das ist was anderes als Authorenzugriff oder Lesezugriff auf ein ganzes Dokument.

Wenn es das sein sollte, kann uns ja dann vielleicht beiden jemand hier helfen, wie diese verflixte Feld-Eigenschaft "PROTECTED" da "benutzerabhängig" rein kommt...

Gruß,
Uwe

[jo@chim]

@sloe: Danke für den Hinweis, die Info mit den Readers-Feldern war mir neu. Das Tool hab ich mir geladen und angesehen: schöne lightweight Ergänzung zum NotesPeek, ebenfalls thX.

@Uwe: zu wissen, man ist nicht allein, erleichtert es, das schwere Los als AIDS-Opfer (Acquired IBM Damage Syndrome) zu tragen  

Die PROTECED Flags habe ich allerdings bei mir nicht gefunden. Falls Ihr eine Ursache findet, wäre ich trotzdem über eine Info dankbar - vielleicht haben beide Fehler ja doch irgendwie miteinander zu tun ...