j-lawyer.org
Erstellte Forenantworten
-
Beiträge
-
Welches Betriebssystem?
Ich vermute eine oder beide dieser Ursachen:
– beAstie-Update in anderem Verzeichnis als initial installiert
– User, der Docker ausführt, hat keine Schreibrechte auf das (neue?) Datenverzeichnis/opt/… bezieht sich auf ein Verzeichnis INNERHALB des Dockers. Das Datenverzeichnis liegt dort, wo der Updatebefehl ausgeführt wurde.
Ohne jedwede Information (Betriebssystem, Logs des Docker-Containers, …) kann ich nicht helfen.
Das Update hat bei allen mir bekannten Installationen funktioniert. Es muss eine Spezifik des genutzten Systems geben.
Daten sind keineswegs weg, der Docker funktioniert nur nicht. beAstie hat keine eigene Datenspeicherung.
VG
Jens / j-lawyer.orgHallo,
für (1) gibt es bereits ein Ticket im GitHub. (3) ist für die kommende Version bereits umgesetzt (Anzahlen an den Tabs auf dem Desktop dargestellt). Für (2) gern ein Ticket erstellen, dann planen wir das mit ein.
VG
JensINGO landet manchmal bei der Erstellung der Wiedervorlage in einem Loop, in dem die Wiedervorlage ständig aktualisiert wird.
Ein häufiger Grund sind fehlende oder falsche Angaben. Im Prompt ggf. explizit den Kalender nennen, in den eingetragen werden soll, und welcher Account (Nutzername) verantwortlich sein soll.
Das ablegen der E-Mail, von der aus die Akte durch INGO erstellt wird, funktioniert noch nicht.
Dafür gibt es noch keine Schnittstelle für den Agenten – ich nehme das mit auf.
INGO aktiviert nicht die Erinnerung im j-lawyer Terminplanungstool.
Ebenfalls eine Lücke in der Schnittstelle.
Manchmal erstellt Ingo den Termin in einer nicht mandatsbezogenen Akte, die wir für unsere Organisation benötigen.
Hier wäre es interessant zu wissen, von wo der Prompt gestartet wird.
Versuche Folgendes:
In wildfly/standalone/configuration/standalone.xml gibt es eine solche Zeile:
<connection-url>jdbc:mysql://localhost:3306/jlawyerdb?serverTimezone=Europe/Berlin&allowPublicKeyRetrieval=true&useSSL=false</connection-url>bitte diesen Wert anhängen:
useInformationSchema=false
bspw. so:
<connection-url>jdbc:mysql://localhost:3306/jlawyerdb?serverTimezone=Europe/Berlin&allowPublicKeyRetrieval=true&useSSL=false&useInformationSchema=false</connection-url>Dienst dann neu starten.
Das ergibt keinen Sinn… die Spalte owner_group in Tabelle cases fasst 50 Zeichen und speichert eine ID aus Tabelle security_groups. Wurde das Schema irgendwie händisch verändert?
VG
Jens / j-lawyer.orgEvtl ist irgendein Wert zu lang. Genaueres ließe sich mittels Systemreport (im Menü „Administration“) sagen.
Viele Grüße
Jens / j-lawyer.orgDie Fehlermeldung kommt direkt von den Server der BRAK – ich kann keine weiteren Details nennen. 0950 kommt aber in der Regel wenn das Zertifikat nicht vollständig für das Postfach freigeschalten ist. Der Postfachinhaber muss mittels Kartenlogin eine Freigabe für das Zertifikat erteilen.
VG
Jens / j-lawyer.orgAm besten eine Sofortsicherung starten und danach den Systemreport einsehen (Menü Administration – Systemreport, dort den Tab „Server“). Das sollte Hinweise geben, warum die Sicherung fehlschlägt.
Wahrscheinlich ist ein falsches Datenbankpasswort in den Einstellungen zur Datensicherung hinterlegt.
VG
Jens / j-lawyer.org
