Dokumente identifizieren

[MKnost]

Hallo, ich hab mal wieder ein Problemchen 

Ein Nutzer erstellt ein Document und in der Maske im PostSave hab ich ein Script welches mir basierend auf einer anderen Maske ein neues Dok mit einigen Daten des aktuellen Doks erstellt (brauch ich für eine spezielle Ansicht)
Wird jetzt das Ursprungsdokument geändert, möchte ich auch gerne das "extrahierte" Dok aufdatieren, nur weiss ich nicht wie ich das identifizieren soll....Hat jemand eine Idee, wie ich das realisieren kann? Oder ist der Ansatz schon für die Wurst???

Code

SubPostSave()
Dim session As New NotesSession
Dim db As NotesDataBase
Dim doc as NotesDocument
Dim success As Variant

Set db = session.CurrentDataBase
Set doc = New NotesDocument (db)
doc.Form = ("Personal") 'Die Maske für die Personaldaten
success = doc.ComputeWithForm(False, False)
If success then
Call doc.Save(true, true)
End If
End Sub

Wär schön, wenn mir jemand da ein bissel auf die Sprünge helfen könnte...

Grüsse Micha

[ascabg]

Hi,

Warum schreibst Du nicht einfach die Doc-Id (DocumentUniqueID) des Dokumentes welches der Benutzer erstellt in ein Feld des Dokumentes welches Du per Script erstellt?

Anschliessend kannst Du ueber

notesDatabase.GetDocumentByUNID( unid$ )

wieder auf Dein erstelltes Dokument zugreifen.


Andreas

[koehlerbv]

Eine rein technische Antwort wäre: Du brauchst eine DocID, die in beiden zusammengehörenden Dokumenten identisch ist (hierfür könnte man die UNID des einen Docs in beiden speichern) und hierüber das zugehörige Dokument identifizieren.

Wichtiger erscheint mir aber, Deinen Lösungsansatz prinzipiell zu evaluieren: Was hast Du überhaupt vor und warum willst Du dafür zwei Dokumente nehmen (was aber Sinn machen kann). Vielleicht beschreibst Du das etwas genauer - vielleicht gibt es ja eine ganz andere Lösung.

Bernhard

PS: Von der direkten Verwendung der UNID (ohne separate Speicherung) rate ich ab - diese ist durchaus "flüchtig", und dann verliert man alle Zusammenhänge.

[ascabg]

@koehlerbv

In wie fern "fluechtig" ?

Notes macht am Ende mit den Antwortdokumenten doch auch nichts anderes, als die UNID des einen Dokumentes in einem Feld des anderen Dokumentes zu speichern. 

Andreas

[koehlerbv]

Du brauchst nur aus irgendeinem Grunde eine Kopie des Dokuments zu machen oder machen zu müssen, und schon ist's vorbei mit der Herrlichkeit. Bei Antwortdokumenten ist dies etwas anderes.

Bernhard

[ascabg]

@koehlerbv,

Bitte entschuldige jetzt meine Antwort, aber mann kann es auch uebertreiben. ("Goldwaage")

Dann duerfte Notes mit auch nicht die Moeglichkeit von Dokumentenlinks anbieten, denn die funktionieren dann ebensowenig.

Andreas

[MKnost]

  ok, hab das vielleicht ein bisschen zu einfach umschrieben. Hier mal genauer...

Unsere Nutzer werden beim Öffnen einer DB aufgefordert, ein persönliches Profildokument auszufüllen. Mit diesen Daten (wo u.a. auch Bilder, Anschriften, Telefonnummern, und weitere Dienstliche Details abgelegt sind) werden jede Menge Vorlagen, Anträge, Formulare usw ausgefüllt. Diese Daten können leider nicht im Adressbuch gepflegt werden, weil wir da keinen Zugriff drauf haben (hat nur ein DomAdmin).

Nun benötigt unser Cheffe aber aus diesen ganzen Persönlichen Daten eine Ansicht mit einigen Feldern daraus (wie Erreichbarkeit usw), was ja aus Profildokumenten nicht möglich ist. Daher der Umweg über ein neues Dokument, aus denen die Daten dann in die Ansicht einfliessen.

Bearbeitet der User nun aber sein Profildok, weil sich seine anschrift geändert hat, muss die Ansicht vom Cheffe natürlich auch geändert werden..... Ich hoffe das war jetzt ein bissel klarer, hat bei mir auch gedauert bis ich rausgefunden hatte was die wollen.....

Grüssle Micha....

[Axel]

Bitte entschuldige jetzt meine Antwort, aber mann kann es auch uebertreiben. ("Goldwaage")

Das hat nichts mit der Goldwaage oder mit Übertreibung zu tun, sondern mit einer möglichst fehlerresistenten Entwicklung einer Datenbank.


Axel

[ascabg]

@Axel,

Dann von mir die Frage.

Wie den geschilderten Sachverhalt realisieren? (ohne Variante Antwortdokument)

Andreas

[Driri]

Hallo,

eine Lösung wäre, die Profildokumente auf normale Dokumente umzustellen. Damit nur jeder User sein "Profil" sieht, kann man ja dann mit Leserfeldern arbeiten. Problem ist dabei vermutlich, daß das eine recht umfangreiche Änderung wäre, wenn da bereits diverse Anwendungen auf die bestehenden Profildokumente zugreifen.

Als Idee :

Beim Speichern des Profildokumentes wird quasi eine Kopie als Childdokument erzeugt. Im Childdokument kann man dann ja wieder Leserfelder verwenden, damit nicht jeder User alle "Profile" lesen kann. Zusätzlich bekommt z.B. eine Rolle Leserberechtigung.
Diese Kopien kann man dann in einer View anzeigen.

Bei Änderungen am Profildokument kann man dann ja über doc.Responses an das Antwortdokument ran und dort die Änderungen nachziehen.

Sicherstellen sollte man dann allerdings, daß immer nur ein Child je Profildokument existiert.

[Axel]

@Axel,

Dann von mir die Frage.

Wie den geschilderten Sachverhalt realisieren? (ohne Variante Antwortdokument)

Andreas

Bernhard hat dir die Antwort bereits gegeben. Siehe Antwort #2

Axel

[koehlerbv]

Was sich hier für mich noch nicht erschliesst: Warum überhaupt zwei Dokumente für eine Information?
Jeder User darf dank Leserfeld nur sein Profil lesen. Da dort aber auch die Chefrolle steht, sieht dieser alle.
So, und nun braucht der Chef nur noch seine eigene Ansicht, und der Fisch ist geputzt.
Oder habe ich was übersehen, Michael?

Bernhard

[m3]

Diese Daten können leider nicht im Adressbuch gepflegt werden, weil wir da keinen Zugriff drauf haben (hat nur ein DomAdmin).

Gibt es auch eine Erklärung, warum dem so ist? Notes ermöglicht hier einen sehr granularen Zugriff, sodass der Admin die Dokumente durchaus aufmachen könnte, weil genau für solche Infos wären sie ja da.

Ansonsten wie Diri schon sagte - umstellen auf normale Dokumente und die Berechtigungen mittels Leser/Autorenfelder anpassen - dann sind auch "Chef-Ansichten" kein Problem mehr (ausserdem wäre das besser wartbar als die Profildokumente - wer löscht wie Profildokumente von MAs, die nicht mehr im Betrieb sind, etc.)

[MKnost]

@m3: Da die Adressbücher in mehreren hundert Servern global vorhanden sind und iene vorgegebene Struktur haben, können wir das leider nicht machen

@Driri: Ich hab noch nicht in der Hilfe geschaut, was ein ChildDokument ist, aber die Lösung klingt gut. Wie müsste ich das Child denn deklarieren?

@Bernhard: Die Maske der Profildoks ist mit Autorenfeldern ausgestattet, d.h., wenn ich noch ein leserfeld einfüge mit der Rolle vom Chef, darf er die doks auch lesen. Aber bekomm ich sie dann auch in eine Ansicht? Ich dachte das geht nicht mit Profildokumenten....

@all danke für eure beiträge

[koehlerbv]

Ich denke, wir reden hier schon lange nicht mehr über Profildokumente?

Wenn Du bisher nur ein Autorenfeld verwendest, können normale Dokumente von allen gelesen werden. Du brauchst als (im normalen) Dokument auch noch ein Leserfeld, welches den Usernamen und die Rolle für den Chef enthält.

Dann sieht jeder nur sein Dokument - ausser der Chef, und das Autorenfeld regelt, dass jeder nur sein Dokument bearbeiten kann, so lange die Benutzer nur Autorenrechte in der DB haben.

Und Du kommst mit einem einzigen Dokument pro Benutzer aus.

Bernhard

[MKnost]

ok ich werd mich da mal ransetzen, die dokumente umzustellen. Das hört sich alles relativ einfach an, mal schauen ob ich das hinbekomm. Da spar ich mir auf jeden Fall das rumhühnern mit den Profildokumenten....

Werd mich aber bestimmt nochmal melden 

[Thomas Schulte]

Bernhard hat recht.

Die Kernfrage lautet, sind das wirklich "echte" Profildokumente, werden sie also über GetProfile... angesprochen, oder sind das einfach nur "normale" Dokumente die umgangssprachlich als Profildokumente bezeichnet werden.

Und bevor du dich da ran setzt

...die dokumente umzustellen.

Ob das wirklich Profiledokumente sind, das bekommt man am einfachsten mit NotesPeek raus, oder indem man sich die Aufrufe im Designer anschaut. Du müsstest mit NotesPeek ja in der Datenbank jeweils pro Benutzer in euerer Firma ein Profildokument finden.

So wie sich das für mich anhört

werden jede Menge Vorlagen, Anträge, Formulare usw ausgefüllt

ist aber das zweite der Fall, denn kein vernünftiger Entwickler löst so etwas mit echten Profildokumenten und den dazugehörenden Caching und Zugriffsproblemen.

Und damit sollte es ja wohl kein Problem sein deinem Chef eine einfache Ansicht in dieser Datenbank zu bauen ohne den ganzen Zirkus mit Dokumente kopieren und dann bitte auch synchron halten.

[MKnost]

Die Dokumente sind "echte" Profile, auch als solche in NotesPeek gekennzeichnet. Das wurde so realisiert, weil die Daten, die darin enthalten sind
1. nur durch den Ersteller einzusehen sowie zu bearbeiten sein sollen
2. alles statische Daten sind und wenn evtl 1-2 mal im Jahr geändert werden (Beförderung, Adresse, Erreichbarkeit, usw)

Ich hab mir das auch nicht selber ausgedacht sondern hätte auch lieber normale Dokumente verwendet, war aber leider eine Vorgabe. Aber wenn ihr überwiegend der Meinung seid, das geht besser mit normalen Dokumenten oder ist mit Profildoks nicht zu realisieren, hab ich wenigstens eine Entscheidungsgrundlage um das umzustellen 

[Axel]

Ich hab mir das auch nicht selber ausgedacht sondern hätte auch lieber normale Dokumente verwendet, war aber leider eine Vorgabe. Aber wenn ihr überwiegend der Meinung seid, das geht besser mit normalen Dokumenten oder ist mit Profildoks nicht zu realisieren, hab ich wenigstens eine Entscheidungsgrundlage um das umzustellen 

Auf jeden Fall hast du es mit "normalen Dokumenten" einfacher, da du sie auch direkt in Ansichten verwenden kannst. Mit dem Einsatz von Leser- und Autorenfeldern kannst du auf ein zweites Dokument (für Cheffe) verzichten. Außerdem umgehst du auch noch die sonstigen Tücken der Profildokumenten (siehe Antwort von Thomas).

Axel

[Thomas Schulte]

1. nur durch den Ersteller einzusehen sowie zu bearbeiten sein sollen
2. alles statische Daten sind und wenn evtl 1-2 mal im Jahr geändert werden (Beförderung, Adresse, Erreichbarkeit, usw)

Wer war denn der Hirnheiner der das vorgegeben hat. Hatte der von Notes auch nur den Schimmer eines Hauchs einer Ahnung? Um diese Anforderung zu realisieren braucht man doch keine Profildokumente. Da tun es simple Leser und Autorenfelder auch, die zusätzlich noch den Vorteil haben das man keine Kopfstände machen muss wenn noch jemand anderes Zugriff auf die Dokumente braucht.

Knallchargen ....