Anhänge in RT-Feldern!

[Heiggo]

Tach Kameraden, Kollegen, Freunde, Bekannte und Unbekannte,

ich müsste mal ´ne Idee oder einen Richtungswink abstauben :-)

Ich bastel gerade an einer recht simplen Datenbank. Diese DB stellt Hauptdokumente und Responses bereit.
Sinn und Zweck der DB soll sein, Dateien für "Andere" bereitzustellen.

Problem 1:
In den Hauptdokumenten soll nur eine grundsätzliche Beschreibung zu den Anhängen stehen, nicht aber der Anhang selber. Da diese Beschreibung aber formatierbar sein soll, benötige ich natürlich ein RT-Feld.

Benötigter Richtungswink Nr. 1:
Hat irgendwer ´ne Idee, wie ich, obwohl es ein RT-Feld ist, verhindern kann, das da doch jemand einen Anhang dranfriemelt?

Problem 2:
In den Responses soll dann der Anhang dranbaumeln. Allerdings nur der Anhang. Hier soll es also sozusagen zum einen umgekehrt sein (ich will gar nicht, das jemand noch Text in das RT-Feld hinzukleistert), und zum anderen möchte ich, das dort nur ein einziger Anhang reinkommt

Benötigter Richtungswink Nr. 2:
Hat irgendwer ´ne Idee, wie ich die Eingabe von Text von vornherein unterbinde?
Benötigter Richtungswink Nr. 3:
Kann man irgendwie dafür sorgen, das tatsächlich nur ein Attachment drangeklammert werden kann?

Randbemerkungen:
Die Fragen sind extra so gestellt, das als korrekte Antworten auch: Ja, ich etc. möglich sind, damit auch Bernhard und Co mal wieder Ihren Spaß haben

Bitte (wenn möglich) keine End-Lösungen, wirklich nur Richtungsweiser. Ich lerne noch und möchte nicht in Versuchung geraten für jeden Kram andere zu belästigen. Wenn ich trotz Richtungshinweisen nicht weiter komme kann ich ja immer noch meinen Allerwertesten auf diesen Stuhl setzen und hier nochmal nachhaken :-)

[eknori]

schwierig seine Frage zu beantworten ist; gar unmöglich mir scheint  

Wie stellst du denn eigentlich den Zusammenhang zwischen Attachment ( im Response ) und Beschreibung ( im Hauptdokument ) her ?.

>> Hat irgendwer ´ne Idee, wie ich die Eingabe von Text von vornherein unterbinde?

würde ich mit HasEmbedded oder so abfragen; wirkt aber dann nur beim Speichern ( QuerySave )

>> Hat irgendwer ´ne Idee, wie ich, obwohl es ein RT-Feld ist, verhindern kann, das da doch jemand einen Anhang dranfriemelt?

RT setzt ja voraus, daß es abgespeicht wird, bevor der Inhalt bekannt ist; jetzt schreibt jemand einen Text rein und hängt gleichzeitig einen Anhang dran; dumm gelaufen. Das wird wohl nicht gehen, sprich kannst du vergessen.

>> Kann man irgendwie dafür sorgen, das tatsächlich nur ein Attachment drangeklammert werden kann?

Auch hier kannst du nur scriptmäßig prüfen, ob schon ein ATT embedded ist; allerdings erst nachdem das doc gespeichert wurde.

es zu realisieren, junger NotesCoder; schwer wird er es haben ...

[Heiggo]

Autsch.... aaalso...
Zusammenhang zwischen Attachment und Beschreibung
Eingebettete Ansicht im Hauptdokument. Ich sammle sämtliche Responses in einer versteckten Ansicht, erste Spalte ist $Ref (kategorisiert ), die ich halt im Hauptdokument mit anzeige, wenn es also mehrere Dateianhänge zu einem Hauptdokument gibt, dann wird das dort halt auch gesammelt angezeigt.

Und da nun sozusagen schon die nächste Frage vorprogrammiert ist wozu soll das ganze gut sein... hier die unbefragte Antwort:
Die Größe einer eMail soll serverseitig (per Konfigurationsdokument) beschränkt werden. Soweit, so gut, das umzusetzen ist natürlich als Domino-Admin-Heini das kleinste Problem. Was aber, wenn es nun doch mal wichtig wird, eine etwas größere Datei an eine entfernte Stelle zu bewegen. Gemäß Weisungslage sind dafür logischerweise Non-Notes-Lösungen (sprich Datenträger á la CDR etc) zu wählen. Was aber, wenn es enorm wichtig ist, das eine größere Datei verdammt zeitnah beim Empfänger sein muss? Das kommt bei uns nicht oft, aber doch schon mal vor. Also hab ich mir gedacht, ich klatsch eine Datenbank auf meinen Applikationsserver, auf dem alle meine Nutzer Zugriff haben, und das sind gut und gerne 3500 schön verstreut in Baden-Würrtemberg und Bayern, die sich dann ihrer Autorenrechte in der DB erfreuen dürfen.
Der Autor kann dann nach einfriemelung seines Anhangs (als Response) dem Empfänger eine schnelle Info mit Verknüpfung zum Hauptdokument schicken, wenn dort bereits ein Anhang dranbaumelt kann es sein, das der Empfänger erstmal ewig wartet, bis sich das Dokument geöffnet hat.
Das möchte ich aber nicht. Der Empfänger soll sich erst in Ruhe die Beschreibung durchlesen können und dann gezielt (und bewusst) den jeweiligen Anhang holen können.


Ich muss halt nur dafür sorgen, das ich ´ne Info (z.B. per eMail) bekomme, sobald einer einen Anhang reinfriemelt. Nicht, das mich der Anhang inhaltlich interessiert, im Gegenteil, der geht mich in der Regel nix an, aber ich möchte natürlich verhindern, das unsinnige (sprich undienstliche) Dateien auf diesem Weg verteilt werden. Automatisches Aufräumen etc. wird dann auch noch später eingefriemelt. Na ja, und was mir noch so alles einfällt, um das Ding gegen Mißbrauch abzusichern.

schwierig seine Frage zu beantworten ist; gar unmöglich mir scheint  

Wie stellst du denn eigentlich den Zusammenhang zwischen Attachment ( im Response ) und Beschreibung ( im Hauptdokument ) her ?.

Ich teste da gerade auf free.dominoserver.de.Sieht im Web ziemlich sch... aus, aber dafür ist es ja auch nicht gedacht :-)
File-Transfer

[eknori]

Ich fasse das mal für mich zusamme:
Mehl ist grössenmäßig begrenzt; aBär es gibt eine DB, wo die Hansel ihre übergrossen Mehls austauschen können.

HMM

Wo liegt dann das Problem, wenn der Ersteller der Mehl Autorenrechte hat ? Wie soll dann ein Dritter da was reinfummeln ?

Kann auch sein, dasß ich das noch nicht richtig erfasst habe ( mir hängt immer noch das Techno Gehämmer von Athens in den Ohren )

[..Andreas..]

zu Problem 1 - Benötigter Richtungswink Nr. 1:

Unter R6 kein Problem (RT-lite), aber unter R5 wohl nur, und am einfachsten, über @Attachments beim Speichern oder Schließen oder Feldwechseln oder Refresh oder oder oder abzufragen.


zu Problem 2 - Benötigter Richtungswink Nr. 2:

Das RT-Feld mit einem Entering-Event ausstatten (LS-only glaube ich), der das "Betreten" des Feldes verhindert.


zu Problem 2 - Benötigter Richtungswink Nr. 3:

Eine Aktion erstellen, die ein Attachment auswählen lässt (@Promp([LocalBrowse], ... oder so, hab gerade kein Notes da), und in das (vorher per Entering-Event gesperrte) Feld "reinpasted". Dazu den Event soausstetten, das die Aktion nicht in den "Verhindern-Status" reinläuft (z.B. über ein temporäres Feld auf dem Dokument)

Ich hoffe das war Denkanstoss genug, und nicht zuviel Information, damit Du selbst noch aktiv nachdenken musst.

Ansonsten schreib nochmal, dann gehts auch noch konkreter.

Schönen Sonntag noch,
Andreas

[Heiggo]

Nene, die sollen da nicht ihre übergroßen Mails austauschen, nur bedient man sich gerne der Mehlsäcke um große Datenmengen zu übertragen. Bekanntermaßen sind aber nur ganz wenige davon wirklich wichtig.
Fallbeispiel:
Ein Fachanwender in unserer untergeordneten Dienststelle in Regensburg hat ein Problem mit seiner Fachanwendung (Access200RT-Basis). Diese Fachanwendung wird betreut von einem Fachanwendungsbetreuer in Stuttgart. Der Fachanwender ruft den Betreuer in Stuttgart an und schildert sein Problem. Um das Problem zu beseitigen kommt nun heraus, das der Betreuer die Daten-Datenbank (wie es so schön heißt) benötigt. Per eMail scheidet nach den neuen Richtlinien und Weisungen aus, aber dennoch benötigt der Betreuer diese größere Datenmenge relativ schnell und kann nicht auf Postlaufzeiten warten, weil der Fachanwender schnell wieder arbeitsfähig sein muss.
Also kann nun der Fachanwender die Daten in der Applikation bereitstellen, dem Betreuer eine Verknüpfungsmail zum Hauptdokument (z.B. mit einer kurzen Problembeschreibung) schicken und dann abwarten, bis der Betreuer mit einer Endlösung aufwartet.

Das mit dem Rumfummeln Dritter könnte auch wichtig sein, denn ich finde es nicht allzu gut, wenn Hans Dampf, der mit dem Fachbereich der das Problem hat, rein gar nichts zu tun hat, vor Neugierde alles an sich reißt und dabei seine eigenen kernaufgaben vernachlässigt. Auch davon haben wir genug. Das Problem zu lösen ist allerdings meine kleinste Sorge :-)

Ist auch nur eine Frage, wer am Ende, wenn das Ding veröffentlichungsreif ist, wirklich darauf zugreifen darf (und mit welchen Rechten). Das ist ebenfalls das kleinste Problem, denn das ist ja ohnehin mein Metier :-)

Ich fasse das mal für mich zusamme:
Mehl ist grössenmäßig begrenzt; aBär es gibt eine DB, wo die Hansel ihre übergrossen Mehls austauschen können.

HMM

Wo liegt dann das Problem, wenn der Ersteller der Mehl Autorenrechte hat ? Wie soll dann ein Dritter da was reinfummeln ?

Kann auch sein, dasß ich das noch nicht richtig erfasst habe ( mir hängt immer noch das Techno Gehämmer von Athens in den Ohren )

[Heiggo]

Tja... R6 steht bei uns noch nicht zur Debatte und wird auch noch einige Zeit dauern. In so einer Megagroßen Gesamtumgebung mit ca. 120.000 Gesamtnutzern und ca. 1500 Servern migriert man nicht mal eben auf die Schnelle auf R6 :-) denn das birgt noch andere Probleme in wunderschönen Mischumgebungen zwischen R4.6 (nicht immer .7 am Ende) und R5.0.11.

Das Betreten des feldes unterbinden klingt nett und klingt auch nicht wirklich nach einem großen unlösbaren Problem für einen jungen NotesCoder, wie Ulrich so schön schreibt. Aaaaaaber... so auf die Schnelle bewertet hätte ich da nicht das Problem, das dem Nutzer dann nicht auch verboten wird, seinen Anhang dranzubaumeln? Wäre ziemlich unpraktisch, denn das ist der Hauptzweck der Datenbank
Das sind aber nur meine Schnellbewertungen.. Ich werde mir das bestimmt noch 30 mal durchlesen und mich damit intensiv beschäftigen. thx (auch an Ulrich)

zu Problem 1 - Benötigter Richtungswink Nr. 1:

Unter R6 kein Problem (RT-lite), aber unter R5 wohl nur, und am einfachsten, über @Attachments beim Speichern oder Schließen oder Feldwechseln oder Refresh oder oder oder abzufragen.


zu Problem 2 - Benötigter Richtungswink Nr. 2:

Das RT-Feld mit einem Entering-Event ausstatten (LS-only glaube ich), der das "Betreten" des Feldes verhindert.


zu Problem 2 - Benötigter Richtungswink Nr. 3:

Eine Aktion erstellen, die ein Attachment auswählen lässt (@Promp([LocalBrowse], ... oder so, hab gerade kein Notes da), und in das (vorher per Entering-Event gesperrte) Feld "reinpasted". Dazu den Event soausstetten, das die Aktion nicht in den "Verhindern-Status" reinläuft (z.B. über ein temporäres Feld auf dem Dokument)

Ich hoffe das war Denkanstoss genug, und nicht zuviel Information, damit Du selbst noch aktiv nachdenken musst.

Ansonsten schreib nochmal, dann gehts auch noch konkreter.

Schönen Sonntag noch,
Andreas

[TMC]

Nun geb ich auch noch meinen Senf dazu ab  

zu "Benötigter Richtungswink Nr. 1":
Du könntest über PostSave / Queryclose abfragen, ob Dein RT-Feld Embedded Objects hat.
Wenn ja: rauswerfen und Backend-Dokument speichern.

zu 2 und 3:
Ich denke mit den Tipps von TtogSeton sollte das so machbar sein.
Z.B. ein uidoc.gotofield("Subject")  im Entering.

[..Andreas..]

Aaaaaaber... so auf die Schnelle bewertet hätte ich da nicht das Problem, das dem Nutzer dann nicht auch verboten wird, seinen Anhang dranzubaumeln? Wäre ziemlich unpraktisch, denn das ist der Hauptzweck der Datenbank

Das Script unterbindet ja nur die "Klick-ins-Feld-Aktion" des Nutzers, nicht die "geh-ins-Feld-Aktion" des Buttons, damit hast Du genau was Du möchtest. Das Script muss dazu irgendeine, von Deinem Button gesetze Variable, zur Entscheidung, ob das Betreten des Feldes nun erlaubt ist oder nicht, heranziehen.

[Heiggo]

Ah ja... glaube, das hab ich kapert :-) darum herum werde ich mal mein Glück in der Entwicklungsabteilung meiner heimischen Wände versuchen :-) erneut... thx.

Das Script unterbindet ja nur die "Klick-ins-Feld-Aktion" des Nutzers, nicht die "geh-ins-Feld-Aktion" des Buttons, damit hast Du genau was Du möchtest. Das Script muss dazu irgendeine, von Deinem Button gesetze Variable, zur Entscheidung, ob das Betreten des Feldes nun erlaubt ist oder nicht, heranziehen.

[TMC]

Was mir noch einfällt:

Warum eigentlich das ganze mit Response-Docs mit Anhang und Parent-Doc mit Text?

Es gibt doch die berühmt/berüchtigte 40K - Beschränkung in den Replizierparametern. Wer also nicht die ganzen Anhänge ziehen will, schaltet diese ein.

Zentrale Ablage von Dokumenten (mit kurzer Beschreibung): Notes ist ideal dafür.

Ich habe Deine Strategie glaub ich noch nicht ganz verstanden.

[Heiggo]

Das Ding wird ja gar nie nicht repliziert. Sagte ich doch, es kommt einzig allein auf einen Applikationsserver.

Ich versuchs nochmal anders:
Ich muss aufgrund neuer konzeptioneller Weisungen die maximale Größe einer übertragbaren eMail serverseitig begrenzen. That´s no prob. Wenn es nun wichtig wird, das eine Datenmenge die oberhalb dieser Grenze liegt von A nach B gelangt, dann muss also diese Datenmenge auf ein Speichermedium geschrieben werden und per Post an den Empfänger gesendet werden. Das ist in der regel auch kein Problem. Wenn aber diese Datenmenge verdammt zeitnah den Empfänger erreichen muss, und der normale Postlauf zu lange dauert und dadurch eventuell der Dienstbetrieb in einem Teilbereich lahmliegt, dann schauen die Nutzer in die Röhre.
Also möchte ich eine Alternative bieten, die im Notfall dem Nutzer ermöglicht seine Daten zu übermitteln. Also kann er sie in die Datenbank einfriemeln, einen Empfänger definieren und dann einen DocLink dorthin schicken, wo er die Daten benötigt.

Ein Fallbeispiel habe ich weiter oben gepostet.

Der Sinn mit Hauptdokumenten mit Text sowie den Responses mit dem Anhang liegt darin, das Nutzer A eventuell in Mannheim und Nutzer B in Regensburg sitzen könnte. Bei uns wäre sogar denkbar, das Nutzer B in Dresden oder Hamburg sitzt. Auch dieser greift aus der ferne auf meinen Applikations-Server zu. Wenn der Nutzer B nun einen Doclink erhält, und er diesen anklickt und daran baumelt zufälligerweise noch eine 57 MB-Datei, dann lädt er das Dokument so lange vom Server, bis er schwarz wird. In der Regel wird das abgebrochen. Der soll aber erst den Begleittext lesen und dann gezielt und vor allem gewollt die Datei auf seine Kiste laden, wenn es denn überhaupt nötig ist.

Es geht hierbei in erster Linie um Supportleistungen für Fachanwendungen, die wir bei uns nicht leisten können. Und davon haben wir verdammt viele. Wir selber sind nur für die Bereitstellung der Anwendungen verantwortlich, müssten wir die Dinger auch noch fachlich supporten wären wir keine IT-Heinis sondern Götter, denn kein IT-Bereich mit 6 Leutchens in der "Technik" kann für 100 verschiedene Fachanwendungen den Support leisten. Dafür gibt es dann die jeweiligen Fachbetreuer und Fachanwendungsentwickler.

Was mir noch einfällt:

Warum eigentlich das ganze mit Response-Docs mit Anhang und Parent-Doc mit Text?

Es gibt doch die berühmt/berüchtigte 40K - Beschränkung in den Replizierparametern. Wer also nicht die ganzen Anhänge ziehen will, schaltet diese ein.

Zentrale Ablage von Dokumenten (mit kurzer Beschreibung): Notes ist ideal dafür.

Ich habe Deine Strategie glaub ich noch nicht ganz verstanden.