- Dieses Thema hat 46 Antworten sowie 6 Stimmen und wurde zuletzt vor vor 8 Monaten, 1 Woche von
aktualisiert.
-
Beiträge
-
Hallo,
der prompte support hat mir den Mut gegeben, auf zwei Rechnern server (linux) und client (ms) gestern einzurichten.
Mir gelang auch das anlegen der Akten, doch stieß ich auch die schwierige Ordnerstruktur/Benennung zu den Akten auf dem server.
Ich bin wie bjk großer Fan der hirachischen Aktenordnerstruktur, die man einfach und auch unabhängig des Programms über das Dateisystem erreichen kann (also bspw. Oberordner 2017 und dann darin 1-17, 2-17 etc.
Dies erleichtert nicht nur die Übernahme aus dem bisherigen Kanzleisoftware, sondern ist nach meiner Erfahrung gegenwärtig auch die schnelleste Möglichkeit der Dokumentenzuordnung bei der Nutzung des beA – also das direkte Speichern der teils vielzähligen Anlagen je Nachricht in den entsprechenden Aktenordner.
Gibt es vielleicht die Möglichkeit, die gegenwärtige Ordnerstruktur und -benennung umzustellen?
Lieben Gruß
Hallo chris und bjk,
noch ein paar Gedanken dazu.
doch stieß ich auch die schwierige Ordnerstruktur/Benennung zu den Akten auf dem server
Es ist nicht vorgesehen, dass Anwender direkt mit der Ordnerstruktur arbeiten. Aus diesem Grund gibt es auch keine „Freigaben“ dieser Ordner, um von anderen Geräten aus darauf zu arbeiten. Es ist schlicht
– ein Sicherheitsthema
– ein funktionales Themaerleichtert nicht nur die Übernahme aus dem bisherigen Kanzleisoftware
Eben das ist funktional nicht unterstützt. Ein Dokument besteht nicht nur aus der Datei in der Ordnerstruktur, sondern ist vielmehr Teil eines erweiterten Datenmodells. Vereinfacht ausgedrückt: beim Hinzufügen/Ändern eines Dokumentes über den Client wird
– das Dokument im Dateisystem abgelegt
– ein Datenbankeintrag für das Dokument erzeugt, mit zusätzlichen Attributen wie bspw. dem Diktatzeichen u.a.
– ein Suchindex für die interne „Suchmaschine“ entsprechend aktualisiert
– ein Eintrag in der Aktenhistorie angelegt, wer zu welchem Zeitpunkt das Dokument hinzugefügt/geändert hat
Ein direktes Arbeiten mit den Ordnern würde alle diese Teilschritte umgehen.schnelleste Möglichkeit der Dokumentenzuordnung bei der Nutzung des beA
Es wird eine beA-Integration in j-lawyer.org geben. Momentan ist noch keine produktive Schnittstelle verfügbar, aber wir stehen in den Startlöchern:
http://trac.j-lawyer.org/ticket/36
http://trac.j-lawyer.org/ticket/186Dort wird dann voraussichtlich auch mit wenigen Klicks eine Datenübernahme in die Akten möglich sein, ähnlich wie es jetzt mit den E-Mails und den Drebisnachrichten umgesetzt ist.
Gibt es vielleicht die Möglichkeit, die gegenwärtige Ordnerstruktur und -benennung umzustellen?
Wir sprechen hier ja schon über eine konkrete technische Änderung (Ordnerstruktur anders organisieren) – ich möchte aber viel lieber nochmal einen Schritt zurückgehen und fragen: was ist das Problem, das Ihr lösen möchtet? Ich sehe momentan zwei Dinge:
– einfache navigierbare Struktur für die Daten, außerhalb des Programmes – das sollte mit dem Ticket von bjk adressiert sein: http://trac.j-lawyer.org/ticket/174
– einfache und schnelle Möglichkeit, extern vorhandene Dokumente zu Akten zuordnen zu können – momentan kann man bereits einfach mehrere Dokumente bspw. auch via Drag & Drop in die Akte ziehen. Wenn es darüber hinaus noch andere Szenarien gibt, die besser unterstützt werden könnten: bitte beschreibt das gern, und macht ein Ticket daraus.Beste Grüße,
Jens
(j-lawyer.org)einfache navigierbare Struktur für die Daten, außerhalb des Programmes
Richtig und zwar aus zwei Gründen:
1. eine einfache Validierung eines Backups
2. Möglichkeit die Daten auch ohne funktionierenden Server zu nutzenDer erste Punkt ergibt sich aus der Erfahrung, dass sich Backups ohne gelegentliche Validierung im Ernstfall aus verschiedenen Gründen als defekt und nicht nutzbar erweisen. Eine Validierung über die Kontrolle der log-Files ist für die meistens Anwender dabei viel zu technisch und wird oft nicht gemacht, zumal systematische Fehler im Backupprozess, die nicht in den log-Dateien auftauchen, nicht erkannt werden. Im einfachsten Fall sollte ein Anwender daher in sein Backup schauen können, um das Vorhandensein der zuletzt gemachten Änderungen zu überprüfen, z.B indem er das zuletzt geschriebene Dokument aufruft. Für ein komprimiertes Backup inkl. Datenbank, wie es j-lawyer verwendet, sollte zumindest eine Art Backup-Explorer vorhanden sein, um Änderungen der Daten direkt im Backup validieren zu können.
Oder die Ordnerstruktur ist eben für den Benutzer lesbar und er kann auf dieser Ebene Daten kontrollieren. Daher mein Wunsch nach einer lesbaren Ordnerstruktur.Der zweite Punkt ergibt sich auch aus rein praktischen Erwägungen. Der Defekt des Servers (Festplatte, Mainboard etc.) dürfte die vermutlich häufigste Ausfallursache sein. Da wohl kaum ein Anwender einen Server inkl. professionellen Support mit definierten Reaktionszeiten im Stundenbreich nutzt, wird die Reparatur solch eines Problems, mit dem Bestellen von Ersatzteilen, bestimmt mehrere Tage dauern. In dieser Zeiten laufen Fristen und es müssen Termine wahrgenommen werden, für die die Akten benötigt werden und damit sollten die Daten allgemein lesbar zur Verfügung stehen. Das muss nicht die direkte Ordnerstruktur sein, die für Einzelakten verfügbare Möglichkeit der Speicherung als HTML-Seite halte ich für eine perfekte Lösung, wenn ich ein automatisches Backup in dieser Form für alle Akten durchführen kann. Eine einfache USB-Fesplatte mit diesen Daten und ich kann an jedem Rechner mit Browser die Akten einsehen. Wenn in diesem Backup die Ordnerstruktur anhand der Aktenzeichen aufgebaut wird, ist das völlig ausreichend.
Das die Speicherung der Dokumente über die Datenbank läuft und eine direkte Speicherung im Datenverzeichnis nicht vorgesehen ist, ist mir bewusst und die fehlende Freigabe der Dokumentenverzeichnisse halte ich für ein sehr wichtiges Sicherheits-Feature (Stichwort Verschlüsselungstrojaner). Darum ging es mir also nicht. 🙂
Viele Grüße
bjk1. eine einfache Validierung eines Backups
2. Möglichkeit die Daten auch ohne funktionierenden Server zu nutzenWäre beides mit dem HTML-Export-Ticket adressiert.
Eine Validierung über die Kontrolle der log-Files ist für die meistens Anwender dabei viel zu technisch und wird oft nicht gemacht
Dazu empfehle ich die E-Mail-Funktionalität im Systemmonitoring. Sofern konfiguriert, erhält man (1) kritische Serverzustände und (2) eine Zusammenfassung der geglückten / fehlgeschlagenen Datensicherung per E-Mail. Äußerst praktisch.
in sein Backup schauen können, um das Vorhandensein der zuletzt gemachten Änderungen zu überprüfen, z.B indem er das zuletzt geschriebene Dokument aufruft
Bei einem inkrementellen Backup sicher sinnvoll. Momentan kann j-lawyer.org nur vollständige Backups.
Für ein komprimiertes Backup inkl. Datenbank, wie es j-lawyer verwendet, sollte zumindest eine Art Backup-Explorer vorhanden sein, um Änderungen der Daten direkt im Backup validieren zu können.
Oder gar einzelne Akten auf einen definierten Stand zurücksetzen zu können. Gern als zusätzliche Anforderung hier rein:
http://trac.j-lawyer.org/ticket/122Grüße,
Jens
(j-lawyer.org)Ich hätte noch einen weiteren Grund hinzuzusetzen: Die nicht unerhebliche Übersichtlichkeit neben des Dateizugriffs auch hinsichtlich der Aktenführung.
Ich bin überwiegend im Bereich des Verwaltungs- und Sozialrechts tätig. Hier kommt es oft zu riesigen Akten, in denen mehrere Verfahren/Bescheide betroffen sind. Vielleicht mag dieser Problematik mit Unterordnern abgeholfen werden können (ich habe diese Funktion hier aber noch nicht gefunden), doch hat sich für mich über die Jahre die saubere Benennung der jeweiligen Dateien, bspw. mit 1-17_150816 im Zusammenhang mit dem Zugriff auf den Aktenordner als sehr nützlich erwiesen. Kurz zur Erklärung, der Zusatz 150816 betrifft hier das Verfahren innerhalb der Akte zum Bescheid vom 15.8.2016. Über den Dateimanager kann nun in einer riesigen Akte durch die Suche nach 150816 jedweder Schriftwechsel/jedes Dokument in diesem Verfahren von den anderen getrennt dargestellt werden. So ist es möglich, innerhalb einer Akte verhältnismäßig übersichtlich Folgeverfahren zu führen und diese nicht getrennt von gescannten Verwaltungsvorgängen in diverse neue Aktenzeichen zu verteilen.
Da hier die Aktenordner auf den server neben der recht kryptischen Benennung schwierig auf den clients anzuzeigen und damit die dateien darin zu sortieren/filtern sind, wäre vielleicht ein Umweg über ein keines Suchfenster im „Dokumente“ -reiter der Akte schön derart, dass nur Dokumente mit 150816 innerhalb der Akte angezeigt werden.
Ich könnte mir aber vorstellen, dass dies erheblich schwieriger zu realisieren sein könnte, als eine simple Suche im jeweiligen Aktenordner.
Ohne dass es hier hingehört, aber es wäre auch sehr schön, wenn im „Beteiligten“ -reiter zu den Beteiligten aktenbezogen die jeweilien Geschäftszeichen/Aktenzeichen angegeben werden könnten. Gerade in Akten mit vielen Beteiligten sind die drei freuen Felder unter „Einene“, die ich dafür mißbrauche, schnell aufgebraucht :). Aber vielleicht mache ich auch nur was falsch.
Schließlich gehört es auch nicht zu diesem Thema, aber ich bin über die prompten feedbacks und das Engagement hier außerordentlich positiv überrascht. Ganz lieben Dank dafür – mag einer der Gründe sein, warum ich nicht aufgebe 🙂
Viele Grüße
ChrisWäre beides mit dem HTML-Export-Ticket adressiert.
Punkt 1 leider nicht, die Validierung des HTML-Exportes ist nicht gleich dem Validieren des Backups. Klingt nach Korinthenkackerei ist aber ein ganz wesentlicher Unterschied, da der HTML-Export ja nicht zurückspielbar ist. Dazu mal en Szenario, wie es mir in den letzten 20 Jahren mehrere Male untergekommen ist.
Ein Anwendungsprogramm erzeugt ein komprimiertes Backup. Der Anwender kopiert dieses Backup, automatisch oder manuell, auf einen Datenträger (früher Diskette, dann Zip-Disk und CDRW, heute USB-Fesplatte oder Stick). Die Festplatte des Rechners geht kaputt, die Daten darauf und auch das dort liegede Backup des Anwednungsprogramms sind weg. Also wird das Sicherungsmedium geholt und:
1. Die Backupdatei auf dem Medium ist nicht lesbar
2. Die Datei ist kopierbar aber beschädigt und kann nicht entpackt werden.
3. Es wurde schon ewig die falsche Datei auf das Medium kopiert (sei es weil das automatische Kopieren einen Fehler machte oder der Anwender)Alle drei Situationen habe ich so erlebt (nein ich war nicht der Anwendner) und ich schätze sie als sehr praxisrelevant ein. Dabei ist der Anwender meistens einer Kontrolle des Backups sehr aufgeschlossen gegenüber aber nur, wenn es für ihn einfach ist und seinem täglichen Umgang mit den Daten entspricht.
Ein Doppelklick auf die Archivdatei und die Kontrolle, ob man das letzte erstellte Dokumente dort findet und extrahieren kann, ist für die Meisten, meiner Erfahrung nach, leicht verständlich und wird dann auch gemacht.Und um auf das eigentliche Thema zurückzukommen, dafür braucht es eine lesbare Ordnerbezeichnung.
Vor allem wäre es gegenüber einem extra Backup-Explorer eine schneinbar schnell umsetzbare Lösung, denn die aktuelle Datenbankstruktur gibt ja schon her, nur die ID-Generierung für eine neue Akte müsste geändert werden. Falls Du es doch in Erwägung ziehst, würde ich mich für einen Praxistest einer Betaversion zur Verfügung stellen.Dazu empfehle ich die E-Mail-Funktionalität im Systemmonitoring. Sofern konfiguriert, erhält man (1) kritische Serverzustände und (2) eine Zusammenfassung der geglückten / fehlgeschlagenen Datensicherung per E-Mail. Äußerst praktisch.
Das habe ich natürlich schon aktiviert aber auch hier eine Anmerkung:
Eine Email, die täglich zur selben Uhrzeit, mit dem immergleichen Inhalt empfangen wird, wird nach ein paar Wochen nicht mehr gelesen. Ich habe noch keine Option gefunden, welche die Zusendung der Zusammenfassung der Datensicherung nur im Fehlerfall erlaubt.
In der jetzigen Form, dürfte der durchschnittliche Anwender einen Fehler beim Backup nicht mitbekommen, weil er die Email nach ein paar Wochen einfach nicht mehr ließt.
Ein Ticket für diese Option habe ich nicht funden. Habe ich es übersehen oder ist es in 1.8.1 vielleicht schon umgesetzt? Ansonsten würde ich es gerne erstellen.Gern als zusätzliche Anforderung hier rein: http://trac.j-lawyer.org/ticket/122
Das Ticket habe ich um den Wunsch eines Backup-Explorers ergänzt. Wenn dies in der Client-Software integriert wird, vielleicht sogar mit einem monatlichen Hinweis, dass der Anwedner doch mal die letzten Änderungen in seinem (externen) Backup überprüfen sollte, wäre das meines Erachtens ein großer Sicherheitsgewinn.
Viele Grüße
bjkChris, vielen Dank für die ausführlichen Hintergründe.
Die meisten Deiner Punkte sind bereits adressiert:
– Dokumente in Ordnerstrukturen: http://trac.j-lawyer.org/ticket/61 (eingeplant für 2.0)
– Referenz / Aktenzeichen der Beteiligten: http://trac.j-lawyer.org/ticket/32 (ebenfalls 2.0)Den Vorschlag mit dem Filter in der Dokumentansicht greife ich gern auf – habe ein neues Ticket erstellt:
http://trac.j-lawyer.org/ticket/194Beste Grüße,
Jens
(j-lawyer.org)1. Die Backupdatei auf dem Medium ist nicht lesbar
2. Die Datei ist kopierbar aber beschädigt und kann nicht entpackt werden.
3. Es wurde schon ewig die falsche Datei auf das Medium kopiert (sei es weil das automatische Kopieren einen Fehler machte oder der Anwender)Da sprichst Du primär organisatorische und/oder technische Defizite an, die genauso zutreffen wenn die Struktur im Backup besser lesbar wäre.
Ein Doppelklick auf die Archivdatei und die Kontrolle, ob man das letzte erstellte Dokumente dort findet und extrahieren kann, ist für die Meisten, meiner Erfahrung nach, leicht verständlich und wird dann auch gemacht.
Okay, das habe ich als Kommentar im Ticketsystem gesehen. Da lässt sich sicher etwas machen.
eine schneinbar schnell umsetzbare Lösung, denn die aktuelle Datenbankstruktur gibt ja schon her, nur die ID-Generierung für eine neue Akte müsste geändert werden.
Nur scheinbar schnell. Mit den nutzerdefinierten Aktenzeichen würde sich die Notwendigkeit ergeben, aus den Aktenzeichen immer einen nutzbaren Ordnernamen zu berechnen (Umlaute, Sonderzeichen, evtl. Encoding-Probleme, …) – das ließe sich sicher implementieren, allerdings nicht risikofrei.
Umgekehrt müsste aus dem Ordnernamen eine Zuordnung zu einer Akten-ID umgesetzt werden, und exakt das wäre nicht eindeutig, wenn man für den Ordnernamen Ersetzungen vornehmen muss. Heisst: Es müsste eine weitere Datei im Verzeichnis hinterlegt werden, wo bspw. die ID drinsteht.Eine Email, die täglich zur selben Uhrzeit, mit dem immergleichen Inhalt empfangen wird, wird nach ein paar Wochen nicht mehr gelesen.
Das steht jetzt aber im Kontrast zu der Annahme, dass Anwender routinemäßig ihre Backups kontrollieren. Ich kann nur von mir ausgehen, aber wenn ich zu faul für Routinetätigkeit A bin, dann bin ich es auch für Routinetätigkeit B 🙂
Die Mailfunktion für die Admins ist so gemacht, dass man leicht anhand der Betreffzeilen filtern kann – bspw. wenn ein Backup fehlschlägt, beginnt die Betreffzeile der Mail mit „Fehlgeschlagen: […]“. So kann man sich gern eine IMAP-Sortierregel o.ä. aufsetzen und nur die „Ausnahmen“ direkt in der Inbox aufschlagen lassen.
Die von Dir angesprochene Einstellung „Mails nur im Fehlerfall“ erscheint trotz allem sinnvoll.
Sofern Dir die monatliche Erinnerung zur Backupverifizierung wichtig ist, dann bitte noch als Kommentar am Ticket ergänzen.
Danke!
Jens
(j-lawyer.org)Da sprichst Du primär organisatorische und/oder technische Defizite an, die genauso zutreffen wenn die Struktur im Backup besser lesbar wäre.
Es geht ja nur darum, die genannten Fehler frühzeitig zu erkennen, nicht sie auszuschließen, und dafür ist eine lesbare Struktur sehr hilfreich.
Wie soll z.B. ein Anwender sonst erkennen, dass sein USB-Stick defekt ist und die Daten eigentlich gar nicht mehr gespeichert werden, wenn er keine Möglichkeit hat, dies zu testen. Der Verweis auf organisatorische und technische Defizite hilft nicht weiter, wenn die Daten weg sind. Ein Backup ohne Prüfung auf Vollständigkeit und Integrität ist kein Backup und das sollte vom Anwendungsprogramm mit geleistet oder zumindest unterstützt werden.Das steht jetzt aber im Kontrast zu der Annahme, dass Anwender routinemäßig ihre Backups kontrollieren. Ich kann nur von mir ausgehen, aber wenn ich zu faul für Routinetätigkeit A bin, dann bin ich es auch für Routinetätigkeit B ?
Tja, alles richtig aber der Mensch ist, wie er ist. Mit Faulheit hat das meistens nichts zu tun, sondern schlicht mit der menschlichen Phsychologie. Die Routine wird ausgeblendet, nur ungewohnte Dinge gelangen in den Fokus der Aufmerksamkeit. Eine Email vom Server jeden Tag um 23Uhr oder einmalig im Fehlerfall ist ein riesen Unterschied.
Und weil Deine Zielgruppe eben Juristen und keine IT-Fachleute sind, die j-lawyer primär nutzen, um ihre Akten zu verwalten und kaum Zeit haben, sich ums Backup machen und deren Kontrolle zu kümmern, wäre ein regelmäßiger, gar nicht mal so dezenter Hinweis darauf auch angebracht.
Du glaubst gar nicht wie dankbar ein Backup-Muffel ist, wenn im Crash-Fall seine Daten alle wieder eingespielt werden können. Der Mensch ist eben, wie er ist. 🙂IMAP-Sortierregeln sind nur etwas für technikaffine Menschen, die meisten Anwender Deines Programms, werden nicht einmal wissen, was IMAP ist, geschweige denn, sich irgendwelche Sortierregeln in ihrem Emailprogramm erstellen.
Viele Grüße
bjkHallo Jens,
ist diese Anleitung noch aktuell? Leider schaffe ich nicht den Zugriff herzustellen.
Mein J-Lawyer Server ist auf meiner Festplatte (lokale Installation auf dem gleichen Notebook wie der Client).
Im aktuellen LibreOffice scheint der MySQL-Connector schon mit instaliert zu sein.
Es gibt jetzt aber noch einen Zusatzmenüpunkt inst man zwischen „Open Database Connectivity“, „Java Database Connectivity“ und „using MariaDB C Connector“ auswählen muss.
Open Database Connectivity scheint etwas anderes als J-Lawyer vorauszusetzen.
Bei Java Database Connectivity kriege ich die Meldung „[Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified“.
Bei der Option „using MariaDB C Connector“ kriege ich die Fehlermeldung „Access denied for user ´[User Name]´(using password: YES)“
Als User Name habe ich hier sowohl „root“, den SQL Zugang „root – xxxxxxxxx“ aus der Installation des J-Lawyer Server und meinen aktuellen Nutzernamen zum Login beim J-Lawyer Client probiert. Die Fehlermeldung ist immer die gleiche.
Was mache ich falsch?
Sollte grundsätzlich noch anwendbar sein. Die Tabelle heißt nur mittlerweile nicht mehr ArchiveFileBean sondern cases.
> Bei der Option „using MariaDB C Connector“ kriege ich die Fehlermeldung „Access denied for user ´[User Name]´(using password: YES)“
Das heißt dass etwas mit dem Passwort nicht stimmt. Wenn die Meldung kommt, hat LibreOffice aber bereits mit der Datenbank kommuniziert. Sollte also gehen.
Ok, der Zugriff hat jetzt geklappt.
Der Punkt war:
User name ist nachwievor „root“ und Passwort das was man bei der Serverinstallation erhalten hat (nicht was man bei Einrichtung der Nutzerkonten selbst vergeben hat).
Ich sehe jetzt zwar verschiedene „Tables“ die ich auch öffnen kann, nur sehe ich keinen Table „ArchiveFileBean“. Und weiter ausklappen kann ich auch nichts mehr.
Muss ich sonst noch einen Zwischenschritt machen, um die Datei zu sehen?
- Du musst angemeldet sein, um zu diesem Thema eine Antwort verfassen zu können.