j-lawyer.org
Erstellte Forenantworten
-
Beiträge
-
Hier das Feedback das ich bekommen habe:
„Es werden beide Parteien als solche eingfügt, d.h. Kläger (Kind, Eltern) oder Beklagter (Kind, Eltern).
Dies ist auch nur ein Problem bei dem sog. Rubrum, d.h. bei der Parteienbezeichnung in der Klage.
In den Schriftsätzen wird die Partei dann meist als Kläger oder Beklagter bezeichnet.“
Grüße,
Jens
(j-lawyer.org)Hallo bjk,
dazu gibt es ein Ticket, allerdings nur im Backlog (d.h. nicht konkret geplant):
http://trac.j-lawyer.org/ticket/40Ich hake mal nach wie einer unserer „Power User“ das praktiziert.
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)Chris, 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. 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)Sind die Änderungen „massentauglich“, d.h. für alle Anwender sinnvoll und anwendbar?
Wenn ja, dann könntest Du Deine Änderungen beisteuern, sodass Du diese Änderungen bei einem neuen Release nicht erneut nachpflegen musst.Es gibt Anwender die noch nicht 100% „paperless“ sind, da kommt das Aktenvorblatt zur Anwendung. Nutzung einer Vorlage wäre möglich und wäre flexibler was das Layout angeht, allerdings dann mit mehr Klicks um es erneut auszudrucken.
Welche Datenfelder vermisst Du?
Grüße,
Jens
(j-lawyer.org)Geändert, wird mit 1.8.1 ausgeliefert:
http://trac.j-lawyer.org/ticket/128Grüße,
Jens
(j-lawyer.org)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)Hier ein Link der helfen könnte:
http://community.jaspersoft.com/wiki/jasperreports-library-tutorialAnsonsten gern ein Ticket erstellen, mit möglichst genauer Beschreibung was geändert werden soll.
Grüße,
Jens
(j-lawyer.org)Ist das archivefile.jrxml das Masterdokument und die anderen files unter reports sind dort eingebunden?
Das ist richtig. Siehe dazu die
-Abschnitte – dort werden die anderen Files referenziert. Also j-lawyer-client.jar auspacken, archivefile.jrxml (und/oder eingebundene Files) anpassen, alles wieder packen und zurückkopieren?
Auch richtig. Vorher natürlich die originale .jar sichern, falls etwas schief gehen sollte.
Der j-lawyer.org Client kompiliert die .jrxml beim Hochfahren.Grüße,
Jens
(j-lawyer.org)Momentan nicht editierbar. Die Layouts liegen in der Datei „j-lawyer-client.jar“ (was auch nur ein ZIP File ist) im Verzeichnis „reports“. Das sind .jrxml-Dateien (für „Jasper Reports“ XML).
Praktisch könnte man diese Daten im ZIP austauschen. Dazu muss man allerdings das XML-Format kennen / sich aneignen.
Grüße,
Jens
(j-lawyer.org)Guter Punkt. Auch wenn das codetechnisch funktioniert, ist es unsauber. Ich liefe heute abend einen Fix.
Jens
(j-lawyer.org)Es wird das Standardschema verwendet. Waren die Anforderungen unvollständig? Ich hatte das nicht explizit herausgelesen, und damit würde „quick & dirty“ auch zu „nicht mehr ganz so quick und clean“ werden – ich müsste auf Konfigurationen des Servers zugreifen und vorhandene Aktenzeichen prüfen.
Ja,
ist das Kurzrubrum. Bitte hier in Hochkommata angeben, da ja Leerzeichen enthalten sein können und diese nicht als einzelne Parameter gewertet werden sollen. Grüße,
Jens
(j-lawyer.org)Download: http://www.j-lawyer.org/temp/casegenerator/j-lawyer-casegenerator.zip
Aufruf in Eingabeaufforderung / Bash:
java -jar j-lawyer-casegenerator.jar <jahr-2stellig> <startindex> <endindex> <name-in-quotes> <mysql-root-passwort>
z.B. Akte 1 bis 20 für Jahr 2010
java -jar j-lawyer-casegenerator.jar 10 1 20 "automatisch erstellt" geheimesPWGrüße,
Jens
(j-lawyer.org)
