Project

General

Profile

fileuploader

Added by Werner Hahn over 3 years ago

Ist das so oder so ähnlich machbar?
Habs nochmal hierher gestellt dass man besser antworten kann.


Replies (2)

RE: fileuploader - Added by Jan Büren over 3 years ago

Hallo Werner,
ich hab das nochmal kurz mit Mosu gemeinsam überlegt.

Das Problem ist hier nicht der Vorschlag für eine Implementierung, sondern die Konzeption des Anwendungsfalls.

Also: Soll der Upload für Mailanhänge sein? Soll der Upload für persistente Daten im WebDAV-Ordner sein?

Bei dem einen Fall kann man die Datei anhängen und überspitzt gesagt, danach wegwerfen, bei dem anderen Fall kommt eine Latte an weiteren zwar lösbaren, aber ätzenden Probleme zutage: Was passiert wen die falsche Datei hochgeladen wurde?
Wer hat Rechte auf die Datei? Brauchen wir Versionierung? ...

Das Problem müsste deshalb nochmal neu angedacht werden. Von unserer Seite (Kundenwunsch / RB-Arbeitsweise) habe ich aktuell zwei Fälle:

a) Präsentationsdateien an Angebote anhängen die per (kivi)-Mail rausgehen
- Hierfür reicht ein Knopf Upload bei der Mail
- Der Anhang ist im E-Mail-Journal persistent zum Zeitpunkt Mailversand archiviert
- Optional kann der Anhang auch im WebDAV des Angebots gespeichert sein, aber dass ist ohne Verknüpfungshinweis erstmal nicht so spannend. Als Minimum sehe ich hier das ein Zeitstampel a la Zeitstempel für WebDAV-Archivierung von Belegen erzeugt wird

b) Original Belege für Einkaufsrechnungen mit kivi-Buchung verknüpfen
Wir machen diese Verknüpfungen, aus guten Grund, über Alfresco, da hier die ganzen Punkte "Wer darf was hochladen und wie benennen und wie ist die Version mit welchen suchbaren Metadaten" ... etc schon von Alfresco gelöst werden.

Was ich mir durchaus vorstellen kann, dass wir hier eine Mini-DMS nachahmen können. Folgende Punkte:

- Wenn die Buchung in kivitendo final ist, ist auch der verknüpfte Beleg final (> keine Versionierungspflicht. Dokument darf danach weder geändert noch gelöscht werden)
Metadaten-Erhebung ist unwichtig, da die Metadaten des Dokuments die Buchungsdaten der Transaktion sind (> keine Metadaten-Erfassung)
Keine Volltext-Indizierung notwendig (s.o.)
- optional: Preview / Thumbnail-Vorschau mit bspw. ImageMagick

Der letztere Punkt wäre für mich ein Argument für eine Verknüpfung nur innerhalb kivitendos. Damit hätte man einen echten Mehrwert für die Qualität der Buchhaltung OHNE Schnittstellen und Upgrade-Probleme mit Dritt-Systemen.

Offen zur Diskussion ...

RE: fileuploader - Added by Werner Hahn over 3 years ago

In erster Linie geht es mir hierbei um Shopbilder. In zweiter Linie um Dateien die ich dem Artikel zuordnen kann. Texte/Infos/zusätzliche Bilder usw. zu den Sorten hier bei DF
zu 1) hier arbeite ich gerade dran und bin bei meinen Überlegungen dabei nur in die DB zu Speichern und nicht ins Webdav, und hab mir da einiges abgeschaut aus dem Pflichtenheft->Textblock->Images
zu 2) bei DF würde es uns denk ich reichen wenn Dateien ins Webdav gelegt werden und kivitendo sichtbar ist welche, aber ne Vorschau wäre schon schön.
3) hab ich noch bei den Pflichtenheften mit dem Titelbild, dass ist aber gerade nicht so wichtig
4) Dein Punk a) Mini DMS reicht hier aus, sodass man die orginal Belege aufm Bildschirm anschauen kann und nicht die analogen Ordner durchsuchen muss. Und ähnl. wie bei den Verkaufsrechnungen nur ein Beleg dort sein kann (Seit wann ist das so, bisher hat kivitendo bei jedem drucken auch dort einen Beleg abgelegt, jetzt aber nicht mehr). Hier hätten auch meine Standartkunden nutzen von die die kivi als Buchführung nutzen.
Also ich mach das erstmal für den Shop fertig, auch wenn wir nur ein Bild z.Z. nutzen, aber es immer wieder Überlegungen gibt auch mehrere nutzen zu wollen.

    (1-2/2)