Fehler beim löschen von privaten Ansichten

[Legolas]

Hallo Forum,

ich habe das Problem, dass ich private Views von Typ "Gemeinsam, privat bei Erstbenutzung" auf dem Server nicht mehr löschen kann.
Ich selbst habe Manager Rechte auf die Anwendung.
Beim Löschen direkt im Designer kommt folgende Fehlermeldung: "Eintrag nicht in Gestaltungsliste" (Siehe Bild1)
Versuche ich die View per Script zu löschen, wird folgende Fehlermeldung geworfen: "Notes-Fehler: Index kann auf dem Server nicht erstell werden" (Sieh Bild 2)

Die privaten Ansichten können gelöscht werden, solange keine Änderung des Selectstatements vorgenommen wurde.
Solange das ursprüngliche Select-Statement eingetragen ist, funktioniert alles bestens.

Die User können sich jedoch individuell das Select-Statement für ihre private View über einen Dialog zusammen klicken.
Per Script wird dann dieses Select-Statement in der privaten View geschrieben. Was auch soweit funktioniert.
Die private View stellt dann den gewünschten Inhalt auch dar!

Nur kann im Anschluss (nach einer manuellen Änderung des Select-Statemant) die private View nicht mehr gelöscht werden was zur Folge hat, dass keine Design-Updates usw.
mehr durchgeführt werden können.

Kennt jemand eine Lösung für das Problem?

Grüße
Legolas



Umgebung
Domino 8.5.3 FP1 englsich
Notes 8.5.3 FP1 deutsch

[koehlerbv]

An private Ordner und Ansichten kommst Du zentral eh nicht (sicher) ran. Wenn dann noch ein (versehentlicher) Eintrag in der ACL steht, dass der User in der DB gar keine privaten Elemente angelegt werden, geht das halt eben doch - aber gespeichert wird im lokalen Desk-Topf. Dann ist endgültig der Krieg verloren.

Ich führe für derartige Elemente zentrale und userbezogene Einstellungen in den Anwendungen. Ändert sich die zentrale Versionsnummer bei einem Update und die persönliche ist nicht entsprechend, wird dem User ein Update angeboten. Das läuft dann (bei "Jo, mach ma!") im Kontext lokal beim User, das private Designelement wird gemeuchelt und wird beim erneuten Öffnen der DB neu erzeugt.

HTH,
Bernhard

[Legolas]

Moin Bernhardt,

danke erst mal für die Rückmeldung.
Ich glaube wir reden allerdings von zwei verschiedenen Dingen.

Ich kann nach einer programmatischen Änderung des Select-Statements eine private View gar nicht mehr löschen bzw. das Design ändern.
Wenn ich mir die Eigenschaften im Designer anzeigen lasse, hat diese einfach keinerlei Einträge mehr.
Daher kommen auch die Fehler die ich gepostet habe.
Das Problem ist reproduzierbar.

Bei mir geht's so:
1) Ein View-Template erstellen, dass als Eigenschaft "Gemeinsam, privat bei Erstbenutzung" besitzt. (Im Designer das Symbol Schlüssel mit einer 1)
2) Dieses View in der Anwendungs-UI aufrufen.   --> (Es wird eine View erzeugt, die als Symbol im Designer nur einen Schlüssel besitzt. Die Eigenschaften wie $Flag usw. sind im Designer vorhanden und die View kann auch wieder gelöscht werden.
3) Das Selectstatement dieser View mit z.B. dem folgenden Code per Agent verändern:
Ansichtsinhalt wird dann korrekt laut neuer Selectionsformel angezeigt!

Code

	Dim ws As New NotesUIWorkspace
	Dim ses As New NotesSession
	Dim db As NotesDatabase
	Dim Doc As NotesDocument
	Dim view As NotesView
	Dim selString As String
 
	Set db = ses.currentdatabase
	Set view = DB.Getview("PrivByAccount")	
	If view Is Nothing Then
		MsgBox "view nicht gefunden!" , 16, "Hinweis"
		Exit Sub
	End If
	
	selString = ws.Prompt(3, "SELECT", "Neuer select: ", "",selString)
	If selString = "" Then
		Exit Sub
	End If
	
	view.Selectionformula = selString
	Call ws.Reloadwindow()

3) Im Designer sich die Eigenschaften dieser View nun anzeigen lassen! Diese sind nicht mehr vorhanden.
--> Die View kann auch nicht mehr gelöscht werden. Weder im Designer noch programmatisch.
Solange keine Manipulation des View-Selectstatements vorgenommen wurde, sind die Eigenschaften vorhanden und die View kann gelöscht werden.

Anmerkung:
Ich hatte bisher diese Anwendungssituation über Ordern abgebildet.
Das Problem ist allerdings, das es inzwischen teilweise mehrere Tausend Dokumete sein können und die User immer wieder
vergessen, die Ordner zu aktualisieren.
Die Aktualisierung dauert natürlich dann auch noch einige Sekunden usw.
Mit einer View die der User individuell mit einem Selektstatement belgen kann, wäre das Problem für alle Zeit behoben.


Grüße
Bernd

[Tode]

Private Views sind IMMER ein "pain in the a....".

Wenn ich so ein Konstrukt brauche, dann baue ich mir die "Private view" als "normale" view nach (mit einem Unique- namen pro Benutzer, z.B. per @Name( [TOKEYWORD] ; @UserName ) oder per Zuweisung in einem Profil- Dokmument @UserName = ViewName_Für_Diesen_User).

Per Script ist es kein Problem, eine View mit einem "Template" zu erstellen.... Es handelt sich dann um eine Ansicht, die ich als Designer immer Kontrollieren / manuell löschen kann (kein $Readers- Feld), und die auch beliebig manipulierbar ist.

Mit Private- Views bin ich schon so oft auf die Schnauze gefallen, dass ich die einfach nicht mehr verwende...

[Legolas]

Moin Tode,

das funktioniert aber nur so lange, wie du "statische" Select-Statements hast und eine überschaubare Zahl von Usern. 
Wenn der User aber selbst wählen kann was er sehen will, wird das nicht mehr gehen.
In meinem Fall können die User die Attribute für das Select-Statement selbst wählen. (Siehe Bild 3)

Grüße
Bernd

[Tode]

Was hat das mit der Anzahl User zu tun? Die Anzahl der Ansichten bleibt gleich.. und ob das jetzt private oder Server- basierte sind, ist dabei ja unerheblich...
In der Gliederung ersetzt Du den Eintrag für die Ansicht durch einen Agenten, der teilweise auf dem Server läuft (user braucht keine Berechtigung um Ansichten anzulegen), und prüft: Habe ich für den User schon eine Ansicht -> Wenn ja: Öffnen, wenn nein -> Erstellen und dann öffnen (einziges Problem, dass beim neu erstellen ggf. die Datenbank einmal erneut geöffnet werden muss).
Diese "öffentliche" Ansicht kannst Du dann mit Deinem bisherigen Script genauso anpassen wie die private (Selektion austauschen, etc)...

Anzahl Ansichten bleibt gleich, Dein Script zur Anpassung der Selektion bleibt gleich, nur die Art der Ansicht ändert sich...
Wie gesagt: Grosser Vorteil: Du kannst als Admin einfach per "Ansicht - Gehe zu" die (versteckten) User- Ansichten öffnen und schauen, was schief läuft, oder sie sogar im Designer anpassen...

Ich habe das mal für ein CRM gebaut, da konnten die User sogar bestimmen, welche Spalten Sie wollten, ob sie sortiert oder kategorisiert sein sollten, welche Selektion, etc...

[Legolas]

Hallo Tode,

da hatte ich dich einfach falsch vestanden!
Ich werde Dein Vorschlag mal umsetzen und schauen ob alles in meinem Sinne funktioniert!

Danke für den Tipp

Grüße
Bernd

[Legolas]

Hallo Tode,

funktioniet bestens!
Danke für den guten Tipp, das erleichtert die Usability für die Anwender erheblich.

Grüße
Bernd

[Tode]

UND die Administrierbarkeit für Dich (das finde ich fast noch wichtiger)... Denn Private Views zu Trouble- Shooten ist ein Albtraum...