Obskure Rechteprobleme: Wo suchen?

[Mitch]

Hallo zusammen,

folgende Situation:

Nach einem Schablonenupdate einer Kundenanwendung erhalten einige Anwender die Meldung "Sie sind zur Durchführung dieser Operation nicht berechtigt" beim Versuch ein Dokument zu speichern (sowohl neue Dokumente erstmalig als auch ihre alten Dokumente).

Grundsätzlich deutet diese Meldung ja auf fehlende Schreib-Rechte hin, aber:

• Die User sind Author in der ACL und dürfen Dokumente erstellen.
• Das Dokument hat ein Authoren-Feld und die User stehen da auch drin
• An den QS der Maske und Teilmasken wurde AFAIR nichts ggü. der Vorgängerversion verändert.
• Wenn ich die Cache.ndk lösche und die Kachel entferne/neu hinzufüge, dürfen die User einmalig ein neues Dokument erstellen. Ein zweites Dokument führt aber wieder zu o.g. Fehlermeldung

Bisher erfolglos - sprich keine Änderung - versucht:

• Cache.ndk, Kachel entfernen, Arbeitsbereich komprimieren (Erfolg nur für ein einziges, neues Dokument).
• Lotus Skript vollständig neu kompilieren lassen.
• Datenbank neu signieren lassen.
• Fixup & Compact laufen lassen.

Meine Vermutung: Da ist was an der Gestaltung defekt. Und da die Schablone auf unserem Testsystem läuft vermute ich, dass bei der Aktualisierung beim Kunden etwas schiefgegangen ist.

Mein nächster Ansatz wäre daher: Eine "leere" Schablone auf die Datenbank spielen. Im Designer prüfen ob irgendwelche Designelemente überlebt haben und diese ggf. löschen. Danach die korrekte Schablone wieder drüber ziehen. Alle Ansichtsindizes und den FT-Index verwerfen und neu aufbauen lassen.

Meine Frage: Hat jemand andere/bessere Ideen was ich zuvor noch prüfen könnte? Macht mein Ansatz überhaupt Sinn?


Gruß,

Mitch

[DerAndre]

Hi,

kann es sein, das die lokale Verschlüsselung von Notes Dir da einen Streich spielt?

[Mitch]

Hey und danke,

es handelt sich aber um eine Datenbank auf einem Server und die Schablone ist nicht lokal verschlüsselt.

Oder habe ich dich missverstanden?

[DerAndre]

Da ist die Frage, wie ist die Schablone auf den Server gekommen?

Über einen Client oder von Server zu Server?

Wenn Du über einen Client gehst, wird die Datenbank aus Sicherheitesgründen sofort lokal verschlüsselt.
Und diese lokal Verschlüsselte Datenbank macht dann Probleme wenn diese auf den Server zurück
kopiert wird.
Ich bekomme das nicht mehr genau hin, ist aber ein netter Fallstrick.

[koehlerbv]

Lokale Verschlüsselung kann man ausschliessen: Es betrifft lt. Mitch nicht alle User, und es ist bereits gelungen, einmal ein Dokument zu erstellen.

Mich: Wenn ein Betroffener ein Dokument, für das er berechtigt ist, im EditMode öffnen will - was passiert dann?

Bernhard

[DerAndre]

Hast Recht Bernhard.

Man ( ich ) sollte sich das gelesene auch Merken. 

[it898ur]

Kann es sein, dass beim Speichern weitere (abhängige) Dokumente im Hintergrund angefasst werden, bei denen das Schreibrecht fehlt - hier werden z. B. Nummerndokumente gern genommen.

Gruß

André

[Mitch]

@André: Ich vermute vom Server aus. Ich habe mal angefragt was in den Datenbankeigenschaften steht.

@Anderer André: Nur lesend auf Konfigurationsdokumente.

@Bernhard: Gute Frage, ich versuche es heraus zu finden. Meine Fehler-Logs deuten allerdings darauf hin, dass das Problem nur beim Erstellen auftritt.


Das Problem ist leider, dass ich nur einen fachlichen Ansprechpartner habe. Und der hat selbst keine Probleme.

Die betroffenen User sitzen dann auch noch in anderen Standorten oder sind nicht immer verfügbar, so dass die Laufwege bei Fragen recht lang sind. Weiterhin haben die ihre IT ausgelagert und müssen dort immer semi-offizielle Anfragen für alle Infos und Aktionen starten (und diese natürlich auch bezahlen). 

Mir ist noch etwas eingefallen:

Normales Speichern (z.B. Strg + S) führt zum o.g. Fehler. Speichern über eine Aktion in Lotus Skript (die noch weitere Dinge erledigt) führt zu o.g. Fehler (der nicht in meinen Errorhandler springt) plus einem weiteren Fehler "Notes-Fehler - UNID des Dokuments kann nicht geändert werden" (welcher in der doc.Save Zeile auftritt und auch brav in meinen Errorhandler springt). An der UNID pfusche ich aber definitiv nicht rum.

[Tode]

Habt Ihr zufällig einen Client- Virenscanner mit Hook in der notes.ini des Clients im Einsatz (McAfee ist da so ein Kandidat), da treten oftmals solche seltsamen Phänomene auf... Evtl. Auch ein Virenscanner auf dem server, aber da habe ich dieses Verhalten noch nicht gesehen (dafür andere seltsame Meldungen)

As
Lso prüf mal auf Clients und server die extmgr... Werte in der notes.ini

[Mitch]

So, Zwischenstand, die ersten Infos sind hier eingegangen:

Es gibt keinen Virenscanner-Hook in der Client-Ini. Nur einen für ZipMail, das nutzen die aber alle dort, also auch nicht betroffene Anwender (wobei ich das Tool bereits kritisch beäuge und als Verursacher anderer Probleme verdächtige).

Auf den Server haben wir keinen Zugriff und ich erhalte auch keine Infos (die verraten mir nichtmals die verwendete Hardware).

Der Zugriff auf Dokumente wo der User Schreibrechte hat wurde noch nicht getestet, das ist wohl untergegangen.  Ich habe aber nochmal dran erinnert.

Bis dahin,

Mitch

[Mitch]

Jetzt fließt's:

Ihm zugewiesene Dokumente (mehrere) kann der User öffnen, bearbeiten und speichern. Neue Dokumente immernoch nicht erstellen. Ich habe jetzt nochmal nachgehakt, ob das nur für die eine Maske gilt oder allgemein.

[koehlerbv]

Das hat nun mit der ursprünglichen Fragestellung nur noch sehr wenig gemein.

Hat der betreffend eUser / seine Gruppe überhaupt die korrekte Einstellung in der ACL zum Erstellen neuer Dokumente??

Bernhard

[Mitch]

Gemäß ACL -> Effektiver Zugriff -> Betroffene Person ausgewählt: Ja, hat er.

Ansonsten: Ja, mich verwirrt das auch. Man hatte mir ursprünglich mitgeteilt, dass alte Dokumente auch Probleme machen.

Mal sehen was da noch kommt, vielleicht habe ich ja Glück und es erwischt einen User wo ich mich mal aufschalten darf.