Ansicht: nur 'Antworten' und 'Antworten darauf' hierarchisch anzeigen

[ekznamu]

Hallo,

bisher wurd das nicht gefordert, aber ich hab es einfach nicht hingekriegt.

Wenn ich eine Ansicht mit 'spezieller Antworthierarchie' mach, geht das und sieht so aus:

Firma (Typ: Hauptdokument)
|
|----Kontakt (Typ: Antwortdokument)
       |
       |-----Vorgang1 (Typ: Antwortdokument)
       |-----Vorgang2
       |-----.......

Nun will ich aber eine weitere Ansicht machen, die bei den Kontakten anfängt.

Kontakt (Typ: Antwortdokument)
   |
   |-----Vorgang1 (Typ: Antwortdokument)
   |-----Vorgang2 (Typ: Antwortdokument)
   |-----.......

Um alles in der Welt, ich habs nicht hingekriegt. Notes will wohl immer ein Hauptdokument oben stehen haben.
Oder bin ich zu blöd ?

Gruß
Uwe

[Peter Klett]

Notes verlangt keine Hauptdokumente als oberste Einheit, wenn "Antwortdokumente hierarchisch anzeigen" nicht angekreuzt ist. Dann kannst Du die Kontakte anzeigen lassen. Allerdings kannst Du dann vergessen, die Antworten zu den Antworten hierarchisch auszugeben, denn das hast Du ja ausgeschaltet.

Also: Geht nicht (bzw. ich wüßte nicht, wie)

[Driri]

Ich wüßte auch nicht wie.

Als einziger Workaround fällt mir ein, daß in die Vorgangsdokumente Daten aus dem Kontakt übernommen werden, so daß man dann darüber eine Kategorisierung bauen kann.

[ekznamu]

@Ingo:

Die Idee hat ich auch, würde auch gehen, aber bei zig tausend Kontakten und noch mehr Vorgängen wär das ne Menge Overhead. Ausserdem muß ja auch etvl. Datenänderung etc. zuverlässig gemanaged werden -> zu aufwendig.

[marschul]

Hallo Uwe,

zumindest richtig sortieren sollte über eine versteckte Spalte klappen, in der Du die UniqueIDs verwendest, in etwa:

@If(Form = "Kontakt"; @Text(@DocumentUniqueID); @GetField("$Ref")) + Form

(letzteres, um z.B. das Kontaktdokument an die erste Stelle zu befördern).
Mit etwas Geschick lässt sich vielleicht sogar eine sinnvolle Kategorisierung erreichen, um die Antworthierarchie nachzuahmen...
"Antwortdokumente hierarchisch anzeigen" darf natürlich nicht ausgewählt sein.

Gruß
Marco

[ekznamu]

@Marco:

auch nicht schlecht.
Hat aber leider auch Nachteile:

Kontakte, die keine Antwortdokumente haben, würden nicht auftauchen
(würde die Anwender verwirren ala: die Datenbank vergißt mal wieder Dokumente .....)

Antworten auf die Antworten würden auch nicht richtig auftauchen, da sie ja nicht den Kontakt als Parent haben.

[marschul]

Hallo Uwe,

doch doch, die Kontakte tauchen auch auf, wenn sie denn in der Selektionsformel enthalten sind. Und die Geschichte mit den Antworten auf die Antworten auf die Kontakte geht auch mit Aneinanderreihung der IDs in der Spaltenformel.

Die Formeln für alle weiteren Spalten sind halt spannend, da sie u.U. die jeweilige Form berücksichtigen müssen, falls Inhalte anderer Felder anzuzeigen sind.

Gruß
Marco

EDIT: Im ersten Satz sind auch die Kontakte gemeint, die keine Antworten haben.

[marschul]

Stop - Irrtum meinerseits: Die Antwort auf die Antwort kennt ja nicht die ID des Kontakts, also wird's, was das betrifft, doch schwieriger 

Gruß
Marco

[ekznamu]

ach jetzt versteh ich. Hast recht.
Bei Antworten auf Antworten könnt ich ggf. über Verkettung der $Refs an die DocUNID des Oberparent kommen.

Werd ich mal drüber nachdenken.

Jetzt ist erstmal Wochenende ............

[Peter Klett]

Stop - Irrtum meinerseits: Die Antwort auf die Antwort kennt ja nicht die ID des Kontakts, also wird's, was das betrifft, doch schwieriger 

Gruß
Marco

Nein, kein Irrtum. Elterndokument von Antwort auf Antwort ist Antwort. Also $REF des Vorgangs muss auf den Kontakt weisen, sonst ist es nicht Antwort von Antwort.

Schwierig wird das Ganze allerdings mit der Sortierung. Die Ansicht soll ja sicher nicht nur nach ID sortiert sein, sondern z.B. nach dem Namen des Kontaktes. Da der vermutlich nicht im Vorgang zu finden ist (deshalb ja die Antwortstruktur, um z.B. Namensänderungen nicht aktualisieren zu müssen), hast Du keine Chance, die Dokumente nach dem Namen zu sortieren oder zu kategorisieren. Du bekommst das hin, dass zusamengehörige Dokumente zusammen angezeigt werden, mehr aber nicht. Sortierung Fehlanzeige.

Eine Möglichkeit wäre, in den Kontakt eine eingebettete Ansicht mit den Vorgängen einzufügen. In der Ansicht dann nur die Kontakte anzeigen. Beim Öffnen sind dann die Vorgänge im Zugriff.

Noch eine Idee, habe ich aber noch nie gemacht. Könnte man nicht in der Dokumentvorschau nur die eingebettete Ansicht anzeigen? Dann wären im oberen Teil der Ansicht die Kontakte und im unteren Teil (der Dokumentvorschau) die Vorgänge (wie gesagt, nur eine Idee ...)

[marschul]

@Peter:
Mit der Sortierung nach Namen hast Du natürlich Recht - sofern dieser Teil nich in allen Doks vorhanden ist, kann auch schlecht danach sortiert werden. Daran hatte ich nicht gedacht.

Die Idee mit der Embedded View in der Vorschau klingt sehr interessant, hat aber das gleiche Problem, wenn noch mehr Antwortebenen hinzukommen, denn die View darf ja auch nicht hierarchisch sein. So wie ich Uwe verstehe, gibt's unter den Vorgängen noch weitere Antworten (das meinte ich dann auch mit 'Stop - Irrtum...').

Soll's schnell gehen und es kommen nicht noch weitere Views auf noch tieferen Antwortebenen als oberste Sortierstufe hinzu, würde ich überlegen, ob der Kontakt zum Hauptdokument geändert werden kann und die Firma eine Eigenschaft in diesem Dokument.

Gruß
Marco

[Peter Klett]

@Marco:

Wenn es noch mehr Ebenen unter den Vorgängen gibt, dann funktioniert das natürlich nicht mehr. Davon steht aber nichts im Ursprungspost. Wäre wohl ein K.O.-Kriterium. Natürlich könnte in allen Dokumenten die ID des Hauptdokuments vorgehalten werden, dann hätte man ein gemeinsames Kriterium, aber schön werden dann die Ansichten nicht mehr.

Die Firma zur Eigenschaft des Kontaktes zu machen würde nur in der speziell gewünschten Ansicht helfen. Strukturell ist es aber nicht ok, da die Beziehung Firma zu Kontakt 1:n ist (gleiche Kontakte in verschiedenen Firmen ignoriere ich mal). Dann hättest Du zwei Kontakte mit der gleichen Firma und müsstest dann die Firmendaten redundant vorhalten und auch ggf. aktualisieren.

In der Ansicht nach Firma hättest Du dann das gleiche Problem, was Du in der Kontaktansicht gerade behoben hast. Strukturell ist der Aufbau so, wie er jetzt ist, sicher am sinnvollsten.

1 Firma - n Kontakte
1 Kontakt - n Vorgänge

[marschul]

@Peter:

Antworten auf die Antworten würden auch nicht richtig auftauchen, da sie ja nicht den Kontakt als Parent haben.

war für mich der Schlüssel, auf weitere Antwortebenen zu schließen...

Deinen Äußerungen bzgl. n x Firma A, B usw. stimme ich zu. Es ließe sich aber realisieren, wenn die Firmendaten in eigenständigen Dokumenten bleiben und als Eigenschaft im Kontakt wird nur der Bezug hergestellt, also die Struktur

n Firmen
1 Kontakt - 1 Firma
1 Kontakt - n Vorgänge

Das ließe sich auch in einer Ansicht darstellen.

Gruß
Marco