Beiträge von Patrick

...das hab ich schon so befürchtet.
Danke für eure Inputs! Auch die Idee mit der DB. Das wäre eine Alternative.

Gibt es eine Möglickeit eine eigene Passwort Komplexität für Web Passwörter zu definieren?
Mit der Security-Poliy kann man eine solche zwar machen, die gilt jedoch nur für Notes-IDs. Ich habe das Problem, dass ich für (ausschliessliche) Webbenutzer eine Firmen-Policy für Passwörter integrieren muss. Dh diese User haben kein ID File und greifen nur per Browser auf Notes Applikationen zu.

Das einzige was man via Security Policy setzen kann, was auch für Web-Passwörter gilt, ist "Required Password Quality". Da kann ich jedoch nur auf vordefinierte Stufen von IBM zurückgreifen, und nichts eigenes definieren.

Die Umgebung ist Notes/Domino 8.5.

Ideen?

Nö, das wär auch zu simpel.

Stimmt. Aber die hab ich eingeschaltet, also daran kann's nicht liegen... Sonst eine Idee?
Es scheint auch nicht an "alten" Templates zu liegen. Habe eben eine neue DB erstellt und hatte das Tools Menü auch nicht...

Wo schalt ich die erweiterten Menüs schon wieder ein?

Hallo zusammen

Wo ist das "Recompile all" im Notes Designer 8.5.1? Ich stehe auf den Script Libraries, aber finde nichts dergleichen im Menü.
Also entweder hab ich Tomaten auf den Augen, oder es existiert nicht.

In der Hilfe und im Web finde ich nur Hinweise, dass es unter "Tools" drin sei. Diesen Menüpunkt hab ich aber gar nicht. Ich hab auch schon versucht den LS-Editor auf Nicht-Eclipse-Based umzustellen, jedoch ohne Erfolg.

Kann mir jemand auf die Sprünge helfen?

...tja ich glaube ich schreibe die Funktion um, und gehe nicht mehr auf doc.ColumnValues.

Danke für eure Inputs!

%edit
Beitrag auf Erledigt gesetzt.

Das würde dann bei meinem Problem heissen, Notes dachte der Index der View sei aktuell, was aber nicht der Fall war?

Und mit SHIFT + F9, oder dem Compact Property hat er den Index tatsächlich gelöscht und neu gemacht, was dann zur "Lösung" des Problems führte.

Wie kann es zu solch einem Problem kommen?

So, ich habe die Datenbank nun vom Kunden bekommen und konnte sie auf meinem System mit vollen Rechten testen. Derselbe Fehler tritt bei mir ebenfalls auf.
Wenn ich die Datenbank jedoch mit dem Admin Client compacte und dabei die Option "Discard any built view indexes" anhake, dann tritt das Problem nicht mehr auf.

Das scheint also ein Fehler mit den View-Indexen zu sein. Übrigens auch ein SHIFT + F9 auf der entsprechenden View funktioniert (der User hatte beim Kunden nur zuwenig Rechte).

Hab mich in der Hilfe noch etwas schlau gemacht. Ein Compact im Notes Client auf der DB nützt nichts, weil dabei die Indexen nicht neu aufgebaut werden. Was ich allerdings nicht ganz verstehe ist, weshalb ein CTRL + SHIFT + F9 nichts nützt. In der Hilfe steht dazu: "Rebuilds all views in a database that are not built; updates all other views"
Heisst das effektiv, dass nur neue Views einen Rebuild wiederfahren, und bei bestehenden quasi ein F9 ausgeführt wird?
Ich war eigentlich der Meinung ein CTRL + SHIFT + F9 sei ein SHIFT + F9 für alle Views...

Es betrifft leider alle User.

Nein, View Selection ist nur das Formular, Spaltendefinitionen sind Verweise auf Felder...

Hab ich auch gemacht.
Und mit CTRL + SHIFT + F9 werden ja alle Views neu indexiert.

Nein, es ist eine normale Shared View.

Ja, die View wird richtig angezeigt beim Kunden. Mit view.GetDocumentByKey findet er das Dokument ja auch.

Version 6.5 bei mir und beim Kunden.

Habe es mit denselben Zugriffsrechten bei mir getestet (Autor mit entsprechenden Rollen). Der Kundenbenutzer hat sogar Editor.

Komisch ist, dass es mit einer neuen Kopie funktioniert, aber mit Fixup und View Rebuild nicht. Was macht Notes bei einer Kopie noch mehr? Ich vermute es muss irgendetwas mit der Datenbank oder mit dem Cache oder ähnliches zu tun haben.

Die Funktion, bei welcher das Problem schlussendlich auftritt, haben wir auch bei anderen Applikationen und Kunden im Einsatz, und es hat noch nie Probleme damit gegeben.

Hallo Forum

Ich habe folgendes Problem: In einer DB habe ich verschiedene Konfigurationsdokumente, welche ich zur Anzeige von Feldern benutze. Via Notes View, hole ich die entsprechenden Daten. Das funktioniert soweit. Nur beim Kunden habe ich das Problem, sobald ich etwas an den Konfigurationsdokumenten (normale Notes-Dokumente) anpasse, dh z.B. Copy/Paste ändern von Einträgen, finde ich zwar mittels vie.GetDocumentByKey, das Dokument, jedoch bringt doc.ColumnValues nicht die richtigen Werte retour.

Ein Requild vom View-Index nützt nichts (CTRL + SHIFT + F9). Wenn ich jedoch die Datenbank kopiere, dann gibt das doc.ColumnValues wieder den richten Wert zurück.
(Ein Fixup der DB hat auch nichts gebracht).

Bei mir kann ich den Fehler nicht nachvollziehen. Ein Ändern der Konfig.-Dokumente ist problemlos möglich und führt zu keinem Fehler...

Ist euch ein ähnliches Problem bekannt, oder habt irgendeine Idee?

Ich hatte dasselbe Problem.
Server: 6.5.5
Client: 6.5.6

Ähnliche Ausgangslage: ich erstellte im Backend ein Dokument und öffnete es schlussendlich im Frontend. Mit Dokument-Locking bekam ich beim zweiten Speichern die Meldung des Konfliktes.

Die Analyse des Problems ergab, dass beim QuerySave das Dokument noch nicht gelockt ist, im PostSave dann schon. Da ich das Dokument im Backend erstellte lief der erste Save sauber durch, nach dem Save (zwischen Query- und PostSave) lockte er dann das Dokument (im Backend), was dann zum Konflikt führte.

Sobald das UIDokument dann geschlossen wurde und erneut geöffnet funktioniert alles korrekt, das Problem trat "nur" beim ersten Öffnen auf.

Mögliche Lösung:
Im QuerySave die Felder $Writers und $WritersDate manuell setzen:

Dim ses As New NotesSession
Call Source.Document.ReplaceItemValue("$Writers",ses.UserName)
Call Source.Document.ReplaceItemValue("$WritersDate", Now)
Call Source.Reload()

Hey Peace, wollte doch nur helfen!

So unerheblich fand ich das nicht, weil "derbearbeiter" in "author" gerechnet wurde... aber egal, schlussendlich hat patri ja die Ursache gefunden.

taurec: das Autorenfeld, Ja. Aber "derbearbeiter" war nicht klar.

Aber klar, wenn es berechnete abhängige Felder auf dem Form hat, bringt computeWithForm den gewünschten Effekt.

Da ist bestimmt ein Feld vorhanden, welches diese default-Werte setzt (computed for display), oder wie Dirk sagt irgendwo im Script (beim Open oder Save oder ähnliches).

Sagt dir der Debugger etwas dazu, wenn du das Profil öffnest?

...das deutet auf falsche Datentypen (names) hin...

- Funktioniert es ohne den Preview Pane vom Parentdoc?
- Benutzernamen für Zugriffsrechte sollten immer in Names-Felder geschrieben werden, nicht in normale Textfelder