Danke für die Rückmeldung, Heiko!

Damit andere das über die Forensuche finden: darf ich kurz fragen woran es lag?

Danke und Gruß,
Jens
(j-lawyer.org)

Ja, das hatte ich mir schon gedacht 🙂

„Berechnen“ würde bedeuten daß das System für einen Tag eine Vorder- und Hintergrundfarbe berechnet und irgendwo ablegt – das würde sicherstellen dass die Kombinationen eindeutig sind (keine zwei Tags mit gleichen Farben), würde die Konfigurationsoberfläche einsparen (und somit Aufwand für GUI und Datenmodell), aber natürlich an Flexibilität einbüßen.

Wenn ich allerdings „bei den meisten Juristen sehr beliebten farbigen Marker“ lese, ist das wahrscheinlich nicht optimal. Also doch lieber die „große“ Lösung, dafür dann eben etwas später geliefert.

Also gern so ins Ticket schreiben.

Gruß,
Jens
(j-lawyer.org)

Danke für die ausführlichen Beschreibung – damit kann ich eine Menge anfangen.

Folgende Anmerkungen:

– Bitte Tickets erstellen zu
(1)
(2)
(4 – am besten mit Wunsch / Prioritätenliste)
(5)
(6 – Würde es reichen wenn j-lawyer.org für jeden Tag eine gleichbleibende Farbe „berechnet“? Ich würde mir gern die Konfigurations-GUI dafür sparen)
(7)
(9 – trivial)
(10)

– Bereits vorhanden: (3 – http://trac.j-lawyer.org/ticket/131)

Sobald ich Tickets habe, mache ich eine Schätzung und sortiere ggf. erste Punkte bereits in die 1.8.1 ein.

Grüße,
Jens
(j-lawyer.org)

Der Wert ist als Maximum zu verstehen, in dessen Grenzen der Serverdienst „atmen“ kann.

In der Regel reichen die 768M für Installationen mit 5 paralleln Nutzern – mal so als Daumengröße.

Grüße,
Jens
(j-lawyer.org)

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)

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)

1. eine einfache Validierung eines Backups
2. Möglichkeit die Daten auch ohne funktionierenden Server zu nutzen

Wä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/122

Grüße,
Jens
(j-lawyer.org)

Geändert, wird mit 1.8.1 ausgeliefert:
http://trac.j-lawyer.org/ticket/128

Grüße,
Jens
(j-lawyer.org)