Classify-Vorschlag: nicht verschieben, sondern eine Replik e

Wenn man eines der m;E. wichtigsten Features von DTPO nutzen will und Dokumente nach automatischen Vorschlägen klassifizieren möchen, entspricht der Button ja “Verschieben”.

Ich würde aber gerne als Standardverhalten haben, dass das Dokument repliziert wird in die neue Gruppe, und in der ursprünglichen Gruppe ein Replikat erhalten bleibt.

Geht das?

Hintergrund: gewisse schlechte Erfahrungen mit dem sonst doch so guten DTPO haben mich zu einem neuen Workflow veranlasst: alle Dokumente kommen in einen Eingangsordner (einer pro Monat) und bleiben da auch. Sie werden von dort in ein oder mehrere Gruppen repliziert.

Dies ist geplant für zukünftige Versionen. Im Augenblick wäre die einzige Möglichkeit, das Dokument per Drag & Drop auf die erste Gruppe zu ziehen bei gedrückten Cmd-Alt-Umschalttasten.

Danke für die schnelle Info. Oh, ja bitte bitte, Feature einbauen… :slight_smile:

Und nicht vergessen: Auch Ganz oben auf der Wunschliste, auch anderer User , ist sicherlich die automatische OCR nicht nur für gescannte Dokumente, sondern auch solche die anderweitig reinkommen.

Könnte man denn nicht bis zur Realisierung “einfach” ein Skript schreiben, das jedes eingehende Dokument in eine “Eingangsgruppe” und eine “Archivgruppe” repliziert?

Dann könnte man die Dokumente der Eingagsgruppe mit einfachem Knopfdruck in die richtige Gruppe verschieben und hätte immer noch ein Exemplar im Archiv.

Ein solches Skript wäre zwar denkbar, aber beim Klassifizieren werden bisherige Replikanten entfernt und das Objekt landet nur in der/den ausgewählten Gruppe(n), so dass es nicht hilfen würde.

Welchen Zweck soll denn die Replikanten konkret erfüllen, den eine intelligente Gruppe nicht bietet?

Es geht darum, folgende “Archivgruppen” zu haben:
Januar 2018
Februar 2018
März 2018 eyc.

In denen die eingegangen Dokumente schnell wieder gefunden werden , und die noch zu keiner anderen Gruppe gehören, sondern eben wirklich “Eingang” sind. Also praktisch die Inbox des SOrters, die alles weiterhin behält.

Einige Dokumente sind unklassizifierbar und bleiben einfach nur so als" im Februar eingegangen", andere sollen mit der intelligenten Klassifizierungsfunktion in eine oder mehrere Gruppen verteilt werden.

Manchmal weiss man nur noch, dass man ca Ende Februar etwas gescannt hat, aber nicht mehr, in welche Gruppe es dann kam.

Würden Sie das mit intelligenten Gruppen lösen?

Zumindest sollte es sich mit intelligenten Gruppen realisieren lassen und hätte dadurch keine weitere automatische oder manuelle Aktionen nötig.

Ich sehe aber ein grosses Problem, das bei uns auch zu Datenverlust bzw zu Schwierigkeiten bei der Datenherstellung geführt haben:

selbst wenn intelligente Gruppen gebildet würden mit dem Kriterium des “Date added”, dieses geht kaputt, sobald man das Dokument von einer Datenbank in die nÄchste kopiert, und man hat keine Ahnung mehr, wann das Dokument in das “Devon UNiversum” eingeführt wurde.

Also beispielswiese habe ich einen alten Scan vom 1.Januar 2015, der im März 2017 in die Devon Datenbank A aufgenommen wird.

Jetzt kopiere ich ihn 2018 als Teil seiner Gruppe in die die Devon Datenbank B.

Dann ist der Timestamp “März 2017” unwiederbringlich verloren! Oder seh ich da was falsch?

Das Hinzufügungsdatum ist tatsächlich datenbank-spezifisch. Mir ist allerdings nicht ganz klar, inwiefern hier Replikanten als Alternative helfen würden.

Und wie gesagt, deswegen hatten wir Riesenprobleme bei der Wiederherstellung von verlorenen Daten.

Und Replikanten würden helfen, weil die “Originale”, also ursprünglichen Verweise auf den Dateien, in der Gruppe “Eingang_März 2018” blieben.

Wenn dann die EIngänge in eine andere Datenbank verschoben werden, weiss man immer noch, wann sie hinzugefügt wurden, und kann tatsächlich durch “Durchblättern” Dokumente wiederfinden, von denen man weiss, wann sie ungefähr hinzugefügt wurden.

Für zukünftige Versionen fände ich es aber schon wichtig, dass Devon einen Timestamp hinzufügt, wann eine Datei aufgenommen wurde, und der nicht beim Wechsel in eine andere Datenbank brutal gelöscht wird. Ganz einfach weil das Standardverhalten bei Drag und Drop von einer Datenbank in die Andere “Verschieben” ist, und daher nicht vorgewarnte User einen ganz wichtigen Parameter verlieren, der für eine vernünftige Archivierung Pflicht ist.

Das würde aber bedeuten, dass die Objekte auch nicht mehr in andere Datenbanken verschoben werden können, da Replikanten datenbank-spezifisch sind.

Zukünftige Versionen werden u.a. benutzerdefinierte Metadaten unterstützen.

Aber warum nicht gleich einen Timestamp automatisch integrieren?
Das Problem von DTPO ist manchmal nicht so sehr eine fehlende Möglichkeit, sondern eher erstaunliche Dinge, die ohne Vorwarnung im Hintergrund stattfinden.

Wenn jemand mal eine ganze Datenbank kopiert jat (ich meine sogar dass das "added " Date bei der Rknostruktion einer Datenbank zerstôrt wird, stimmts?), dann ist’s zu spät.

Seit einigen Versionen bleibt dieses Datum bei einem Neuaufbau erhalten.

Prima, dann bleibt neu hinzukommenden Usern erspart, was uns widerfuhr :slight_smile: