Paketieren, installieren und aktualisieren

Ein NXM-Modul kommt als eine einzige Datei in den Mandanten. Eine Entwicklerin oder ein Entwickler baut sie aus dem Ordner des Pakets und signiert sie mit dem eigenen Schlüssel. Ein Administrator lädt sie hoch, entscheidet, ob der Mandant diesem Schlüssel vertraut, sieht genau, was das Paket mitbringt und welche Daten außerhalb seiner eigenen es nutzen will, stimmt zu, vergibt Rollen und installiert. Spätere Versionen aktualisieren die Installation an Ort und Stelle, samt Datenmigration. Beim Deinstallieren bleiben die Daten entweder für später erhalten, oder sie werden gelöscht.

Nehmen wir wieder Brandt & Söhne. Der Lieferant schickt acme.leihgeraete-1.0.0.nxm. Bevor irgendetwas installiert ist, sieht der Administrator auf einer Seite: Das Paket bringt ein Fachobjekt, zwei Menüeinträge, zwei Rollen und fünf Werkzeuge für den KI-Assistenten mit, es nutzt keine Daten außerhalb seiner eigenen, und der Lieferant hat es mit einem Schlüssel signiert, den der Mandant noch nicht kennt. Der Administrator vergleicht den Fingerabdruck des Schlüssels mit dem, den der Lieferant per Mail geschickt hat, und vertraut ihm mit einem Klick. Erst danach ändert sich etwas im Mandanten.

1. Bauen

   module-package.mjs packt den Paketordner und listet jede Datei mit ihrem Hash.

2. Signieren

   Der Herausgeber signiert die Hashliste mit dem eigenen Ed25519-Schlüssel. Anmelden muss er ihn nirgends.

3. Hochladen

   Ein Administrator lädt die .nxm-Datei im Reiter Pakete hoch.

4. Prüfen und vertrauen

   Hashes, Signatur, Schema und Regeln, alle Probleme auf einmal. Der Mandant entscheidet, ob er dem Schlüssel vertraut.

5. Installieren

   Zustimmung, Rollen, auf Wunsch Beispieldaten. Das Modul ist da.

Vom Ordner zum laufenden Modul. Im Mandanten ändert sich nichts, bevor der Installationsdialog bestätigt ist.

Bevor Sie beginnen

• Administratorrechte im Mandanten. Den Paketkatalog und jedes Installieren, Aktualisieren und Deinstallieren gibt es nur für Administratoren. Alle anderen landen auf dem Dashboard.
• Ein Paket, also eine .nxm-Datei von einem Herausgeber oder ein Paketordner, den Sie selbst gebaut haben (siehe Ihr erstes Modul).
• Für ein signiertes Paket eines neuen Herausgebers: den Fingerabdruck seines Schlüssels, den Ihnen der Herausgeber auf einem anderen Weg als das Paket genannt hat (Mail, Telefon, seine Website), damit Sie ihn vergleichen können (siehe Dem Herausgeber vertrauen).

Eine Version paketieren

Dieser Teil richtet sich an Entwickler. Eine ausgelieferte Version ändert sich nie mehr. Dafür gibt es zwei Wege: Jede Version liegt in einem eigenen Ordner, der wie die Version heißt (acme.leihgeraete/1.0.0), oder das Paket hat einen einzigen Ordner mit der aktuellen Version, und jede ausgelieferte Version ist ein Git-Tag wie acme.leihgeraete-v1.0.0. Weil das Skript aus denselben Dateien immer dasselbe Archiv baut, lässt sich eine ältere Version aus ihrem Tag jederzeit neu bauen. Ob eine neue Version die Regeln einer Aktualisierung einhält, prüft validatePackage gegen die letzte (siehe Auf der Kommandozeile und in CI).

1. Besorgen Sie das Paketier-Skript module-package.mjs. Es liegt in den nexxus-Quellen unter backend/scripts/, läuft mit Node.js und braucht keine weiteren Pakete.

2. Bauen Sie das Archiv aus dem Paketordner:

   node module-package.mjs build acme.leihgeraete/1.0.0

   Das Skript braucht module.json mit kind, key und version und eine Überschrift ## [1.0.0] in CHANGELOG.md. Es packt jede Datei des Ordners (Dateien mit Punkt am Anfang bleiben draußen), legt MANIFEST.sha256 mit einer Zeile <sha256> <pfad> je Datei dazu und schreibt acme.leihgeraete-1.0.0.nxm. Mit --out <datei.nxm> wählen Sie einen anderen Namen. Die Einträge sind sortiert und tragen feste Zeitstempel, derselbe Ordner ergibt also immer dasselbe Archiv.

3. Lesen Sie das Archiv zur Kontrolle zurück:

   node module-package.mjs verify acme.leihgeraete-1.0.0.nxm

   verify prüft, ob jede Datei mit dem richtigen Hash aufgeführt ist, ob nichts fehlt oder zu viel ist, und die Changelog-Überschrift. Die Antwort sieht etwa so aus: acme.leihgeraete-1.0.0.nxm: acme.leihgeraete 1.0.0, 5 Dateien, Hashes stimmen, unsigniert. Den Inhalt des Manifests prüft nexxus beim Hochladen, nicht das Skript.

Ohne das Skript

Auch ein einfaches ZIP des Paketordners ist ein gültiges Paket. Ohne MANIFEST.sha256 und SIGNATURE gilt es als unsigniert und wird nur in Mandanten angenommen, die unsignierte Pakete zulassen.

Das Paket signieren

Die Signatur belegt, dass das Paket vom Besitzer eines Schlüssels stammt und dass sich nach dem Signieren keine Datei geändert hat. Sie signieren mit Ihrem eigenen Schlüssel. Weder der Betreiber der Instanz noch Systaro muss ihn vorher kennen: Jeder Mandant entscheidet selbst, ob er ihm vertraut. Unsignierte Pakete nimmt ein Mandant nur an, wenn sein Administrator sie zulässt.

1. Erzeugen Sie einmalig ein Schlüsselpaar:

   node module-package.mjs keygen ~/keys/acme.pem

   Das Skript schreibt einen privaten Ed25519-Schlüssel (PKCS#8-PEM, nur für Sie lesbar) und gibt den öffentlichen Schlüssel und seinen Fingerabdruck aus, den SHA-256 des Schlüssels in Vierergruppen aus Hex-Ziffern. Eine vorhandene Datei überschreibt es nie. Der private Schlüssel gehört in kein Repository.

2. Bauen Sie mit dem Schlüssel und einer frei gewählten Schlüssel-Id:

   node module-package.mjs build acme.leihgeraete/1.0.0 --key ~/keys/acme.pem --key-id acme-2026

   Das Archiv enthält jetzt eine Datei SIGNATURE: {"keyId": "acme-2026", "alg": "Ed25519", "sig": "<base64>", "publicKey": "<base64>"}, eine Signatur über MANIFEST.sha256 und den öffentlichen Schlüssel, mit dem sie sich prüfen lässt. Das Skript gibt Schlüssel und Fingerabdruck noch einmal aus. Die Schlüssel-Id ist nur ein Name für Sie; nexxus erkennt einen Schlüssel an seinem Fingerabdruck.

3. Prüfen Sie die Signatur:

   node module-package.mjs verify acme.leihgeraete-1.0.0.nxm

   verify prüft die Signatur mit dem öffentlichen Schlüssel, den das Paket nennt, und endet mit Signatur gültig, Fingerabdruck <Fingerabdruck>. Mit --public-key <base64> besteht es darauf, dass das Paket genau diesen Schlüssel nennt.

4. Nennen Sie den Administratoren, die Ihre Pakete installieren, den Fingerabdruck, und zwar auf einem anderen Weg als das Paket: per Mail, auf Ihrer Website, am Telefon. Daran erkennen sie, dass das Paket wirklich von Ihnen kommt.

Signieren Sie spätere Versionen mit demselben Schlüssel. Ein Mandant, der ihm einmal vertraut, installiert jede spätere Version damit ohne neue Rückfrage.

Dem Herausgeber vertrauen

Dieser Teil ist für Administratoren. Ein gültig signiertes Paket mit einem Schlüssel, den der Mandant noch nicht kennt, nimmt nexxus beim Hochladen an. Installieren lässt es sich erst, wenn Sie dem Schlüssel vertrauen.

1. Laden Sie das Paket wie unten beschrieben hoch. Der Katalog zeigt in der Spalte Herkunft den Chip Unbekannter Herausgeber.

2. Öffnen Sie das Paket. Der Hinweis Unbekannter Herausgeber nennt den Herausgeber aus dem Manifest und die Schlüssel-Id und zeigt den Fingerabdruck. Die Karte Herkunft rechts wiederholt Herausgeber, Vertrauen, Schlüssel und Fingerabdruck. Installieren bleibt gesperrt.

3. Vergleichen Sie den Fingerabdruck mit dem, den Ihnen der Herausgeber genannt hat. Weicht er ab, vertrauen Sie dem Schlüssel nicht: Dann hat jemand anderes das Paket signiert.

4. Klicken Sie auf Diesem Herausgeber vertrauen. Der Dialog Diesem Herausgeber vertrauen? zeigt den Fingerabdruck noch einmal. Bestätigen Sie mit Vertrauen. Der Chip wechselt auf Vertraut, und Installieren ist frei, ohne dass Sie das Paket noch einmal hochladen.

Hat Ihnen der Herausgeber den öffentlichen Schlüssel selbst geschickt, können Sie ihm vertrauen, bevor ein Paket da ist: Im Reiter Herausgeber (Route /modules/herausgeber) klicken Sie in der Karte Vertraute Schlüssel auf Schlüssel hinzufügen, fügen den Schlüssel bei Öffentlicher Schlüssel ein und vergleichen den Fingerabdruck, den der Dialog beim Tippen berechnet (Stimmt er mit dem überein, den der Herausgeber Ihnen genannt hat?). Herausgeber (optional) und Name des Schlüssels (optional) dienen Ihrer eigenen Übersicht. Vertrauen speichert. Der Schlüssel ist base64 mit 44 Zeichen, so wie module-package.mjs keygen ihn in der Zeile „öffentlicher Schlüssel“ ausgibt; die DER-Form und ein Block -----BEGIN PUBLIC KEY----- gehen auch. Passt der Text nicht, sagt der Dialog, woran es liegt, zum Beispiel wenn es ein privater Schlüssel ist.

Der Reiter Herausgeber

Der Reiter Herausgeber zeigt, wem dieser Mandant vertraut:

• Unsignierte Pakete zulassen: standardmäßig aus. Solange der Schalter aus ist, lehnt nexxus unsignierte Uploads ab, und eine unsignierte Version lässt sich nicht installieren. Lässt die Instanz unsignierte Pakete für alle zu (siehe unten), steht auf der Seite Diese Instanz lässt unsignierte Pakete für alle Mandanten zu; der Schalter ändert daran nichts.
• Vertraute Schlüssel: jeder Schlüssel, dem der Mandant vertraut oder den er entfernt hat, mit Herausgeber, Schlüssel-Id, Fingerabdruck, seit wann und von wem, und Links zu den hochgeladenen Versionen, die damit signiert sind.
• Schlüssel der Plattform: Schlüssel, die der Betreiber für die ganze Instanz eingetragen hat. Ihnen vertraut jeder Mandant; entfernen lassen sie sich hier nicht.

Entfernen nimmt das Vertrauen nach der Frage Schlüssel von „acme“ entfernen? zurück (Laufende Installationen laufen weiter. Neue Uploads, Installationen und Upgrades mit diesem Schlüssel werden abgelehnt.). Der Schlüssel bleibt als Entfernt in der Liste, seine Pakete zeigen Schlüssel entfernt. Wieder vertrauen macht das rückgängig.

Den Reiter sehen und ändern nur Administratoren; nexxus prüft das auch auf dem Server. Der KI-Assistent kann einem Administrator sagen, welchen Herausgebern der Mandant vertraut und welche Pakete sich deshalb installieren lassen. Einem Schlüssel vertrauen, ihn entfernen oder den Schalter umlegen kann der KI-Assistent nicht; er verweist auf diese Seite.

Schlüssel, denen die ganze Instanz vertraut

Wer die Instanz betreibt, kann einem Schlüssel in der Konfiguration für alle Mandanten vertrauen. So sind die Pakete von Systaro selbst signiert.

nexxus:
  modules:
    trusted-keys:
      systaro2026: <öffentlicher Schlüssel in base64>
    allow-unsigned: false

trusted-keys nimmt den base64-Text des rohen 32-Byte-Schlüssels (so, wie keygen ihn ausgibt) oder seiner DER-Form. Ein Paket mit derselben Schlüssel-Id, aber einem anderen Schlüssel gilt durch diesen Eintrag nicht als vertraut: nexxus vergleicht Fingerabdrücke, keine Namen. allow-unsigned lässt unsignierte Pakete für alle Mandanten zu. Fehlt die Angabe, lässt nexxus sie auf Instanzen mit dem Spring-Profil development, local oder demo zu; überall sonst entscheidet jeder Mandant mit seinem Schalter.

Die Herkunft eines Pakets

Die Spalte Herkunft im Katalog, die Paketseite und ihre Karte Herkunft zeigen für jede Version eines davon:

Beschriftung	Bedeutung
Plattform	Kommt mit nexxus oder ist mit einem Schlüssel der Plattform signiert. Hinweis: Kommt mit NEXXUS oder ist mit einem Schlüssel der Plattform signiert, dem alle Mandanten vertrauen.
Vertraut	Mit einem Schlüssel signiert, dem dieser Mandant vertraut. Hinweis: Mit einem Schlüssel signiert, dem dieser Mandant vertraut.
Unbekannter Herausgeber	Gültig signiert, aber dem Schlüssel vertraut hier noch niemand. Installieren lässt es sich erst, wenn Sie ihm vertrauen.
Schlüssel entfernt	Mit einem Schlüssel signiert, den dieser Mandant entfernt hat. Laufende Installationen laufen weiter; neu installieren oder aktualisieren lässt sich damit nichts. Der Reiter Module zeigt den Chip auch beim installierten Paket.
Unsigniert	Ohne Signatur. Nur angenommen, solange unsignierte Pakete zugelassen sind, und immer mit der Warnung Nicht signiert. Prüfen Sie die Herkunft, bevor Sie es installieren. Installierte unsignierte Pakete tragen den Chip Unsigniert auch im Reiter Module.

Hat die installierte Version eine andere Herkunft als die neueste, zeigt der Katalog zusätzlich einen Chip wie installierte Version: Unsigniert.

Ein falscher Hash oder eine Signatur, die nicht zu ihrem Schlüssel passt, lehnt nexxus immer ab, egal wer signiert hat.

Das Paket hochladen

1. Öffnen Sie AdministrationBetriebModule und wechseln Sie auf den Reiter Pakete (Route /modules/pakete). Der Reiter Module daneben listet die eingebauten Module und die installierten Pakete mit Version und Changelog. Pakete tragen dort den Chip Paket.

   /modules

   

   Installierte Pakete stehen neben den eingebauten Modulen, mit Version und Changelog.

2. In einem Mandanten ohne Pakete zeigt die Seite Noch keine Pakete mit der Schaltfläche Paket hochladen (.nxm). Sonst listet der Katalog jedes Paket mit den Spalten Paket, Version, Stand und Herkunft. Mit Pakete durchsuchen und den Filtern Alle, Installiert, Nicht installiert und Updates finden Sie ein bestimmtes.

   /modules/pakete

   

   Der Weg in den Katalog führt über das Hochladen einer .nxm-Datei.

   /modules/pakete

   

   Stand, wartende Updates und Herkunft auf einen Blick.

3. Klicken Sie unten auf Paket hochladen (.nxm) und wählen Sie die Datei (.nxm oder .zip).

4. nexxus prüft die Datei. Nimmt es sie an, erscheint der Hinweis Leihgeräte 1.0.0 hochgeladen. und die Paketseite dieser Version öffnet sich. Lehnt es sie ab, bleibt ein roter Hinweis stehen: „acme.leihgeraete-1.0.0.nxm“ wurde nicht angenommen., darunter der Grund des Servers und eine Zeile je Problem. Korrigieren Sie das Paket und laden Sie es erneut hoch.

   /modules/pakete

   

   nexxus nennt alle Probleme eines abgelehnten Pakets auf einmal.

Gespeichert wird das Paket nur für Ihren Mandanten. Das Hochladen installiert noch nichts.

Die Paketseite lesen

Die Paketseite (/modules/pakete/<key>) zeigt die neueste Version, außer Sie wählen mit den Schaltflächen neben Version eine andere. Alles darauf stammt aus dem Manifest. Installiert ist noch nichts.

/modules/pakete/curiaos.kanzlei

Alles, was ein Paket mitbringt, bevor etwas installiert ist.

Teil	Was er Ihnen sagt
Kopf	Name, Beschreibung, Schlüssel, der Chip für die Herkunft und nach der Installation Stand und Version.
Herkunft	Herausgeber, Vertrauen, Schlüssel-Id und Fingerabdruck der angezeigten Version. Lässt sich die Version wegen ihrer Herkunft nicht installieren, sagt ein Hinweis oben auf der Seite, was zu tun ist.
Was das Paket mitbringt	Je eine Zeile: Fachobjekte, Menüeinträge, Ansichten mit dem Ort, an dem jede erscheint, Rollen mit ihren Rechten, Daten außerhalb des Pakets, Externe Dienste mit Host und den Ereignissen, die sie bekommen, Werkzeuge für den Assistenten (die Werkzeugnamen für den KI-Assistenten) und Rechte mit ihren vollen Schlüsseln. Leere Zeilen lauten keine.
Änderungen	Der Changelog der Version.
Installation	Nach der Installation: Stand, Version, Installiert am, Installiert von, Zuletzt aktualisiert und Zugestimmt, die Liste dessen, dem Sie zugestimmt haben. Davor: Nicht installiert.
Einstellungen	Nur wenn die installierte Version Einstellungen mitbringt.
Ereigniszustellungen	Nur wenn die installierte Version externe Dienste nutzt.

Am genauesten lesen Sie die Zeilen Daten außerhalb des Pakets und Externe Dienste. nexxus schreibt jeden Punkt als Satz, den technischen Schlüssel daneben:

Schlüssel	Angezeigt als
core:partner:read	Partner lesen
core:user:read	Benutzer lesen
core:dmsDocument:read	Dokumente lesen
core:dmsDocument:create	Dokumente anlegen
core:partnerContact:read	Ansprechpartner lesen
core:partnerContact:create	Ansprechpartner anlegen
core:project:read	Projekte lesen
core:invoice:create	Rechnungsentwürfe anlegen
core:invoice:read	Rechnungen lesen
core:opportunity:read	Opportunities lesen
core:opportunity:create	Opportunities anlegen
core:ismsMeasure:create	ISMS-Maßnahmen anlegen
core:partner:create	Kontakte anlegen
core:mail:send	E-Mails im Namen Ihrer Organisation versenden
service:fristendienst@fristen.example.com	Dienst „Fristendienst“ unter fristen.example.com aufrufen und ihm Ereignisse schicken

E-Mails im Namen Ihrer Organisation versenden erlaubt den Mail-Aktionen des Pakets, über den Mailserver Ihres Mandanten zu versenden, mit einem Brief als PDF unter Dateien. Jede Mail geht trotzdem erst hinaus, wenn ein Mensch sie nach einem Blick auf die Vorschau versendet, und nur an die Adresse, die im Kontakt steht. Der KI-Assistent bekommt eine solche Aktion nie.

Das Paket installieren

1. Klicken Sie auf der Paketseite in der Aktionsleiste auf Installieren. nexxus berechnet zuerst einen Installationsplan. Der Dialog Leihgeräte installieren öffnet sich mit der Unterzeile Version 1.0.0.

2. Lesen Sie die Hinweise oben. Ein unsigniertes Paket zeigt Dieses Paket ist nicht signiert. Installieren Sie es nur, wenn Sie wissen, woher es kommt. (Solange die Herkunft das Installieren nicht erlaubt, ist Installieren schon auf der Paketseite gesperrt, siehe Dem Herausgeber vertrauen.) Lässt sich das Paket nicht installieren, nennt ein roter Kasten So lässt sich das Paket nicht installieren: die Gründe, und die Schaltfläche zum Installieren bleibt gesperrt.

3. Haken Sie unter Ihre Zustimmung jeden Punkt an: Diese Daten und Dienste darf das Paket nutzen, sobald es installiert ist. Haken Sie jeden Punkt an. Die Schaltfläche bleibt gesperrt, bis alles angehakt ist. Ein Paket, das nichts davon braucht, sagt Das Paket nutzt keine Daten außerhalb seiner eigenen.

4. Wählen Sie unter Rollen zuweisen für jede Rolle des Pakets die Personen aus: Feld Personen auswählen öffnen, Namen anklicken und mit Anwenden übernehmen. Angeboten werden nur Personen, keine Dienst- oder Systemkonten. Wen Sie hier auslassen, der kann die Rolle später im Rolleneditor bekommen.

5. Bringt das Paket Beispieldaten mit, entscheiden Sie über Beispieldaten anlegen: Legt erfundene Musterdatensätze und -dokumente an, zum Ausprobieren. Der Haken ist zu Beginn nicht gesetzt. Lassen Sie ihn in produktiven Mandanten weg.

6. Klicken Sie auf Installieren. Der Hinweis Leihgeräte ist installiert. bestätigt es. Lehnt der Server ab, bleibt der Dialog offen und zeigt Nicht installiert: mit dem Grund.

   

   Jeder Punkt der Zustimmung muss angehakt sein; die gewählten Personen bekommen die Rolle sofort.

Die Menüeinträge des Moduls erscheinen sofort und ohne Neuladen im Menübereich seines Fachbereichs. Administratoren sehen alles. Alle anderen sehen das Modul erst mit einer seiner Rollen. Schaltet der Mandant diesen Fachbereich ab, bleibt das Modul trotzdem da; verbergen lässt es sich nur durch Deaktivieren.

Was im Hintergrund passiert

Die Installation läuft in einer Transaktion. Entweder passiert alles oder nichts.

• Installation. nexxus speichert die Installation mit dem Stand Aktiv, der Version und der Liste dessen, dem Sie zugestimmt haben.
• Rollen. Für jede Rolle im Manifest legt nexxus eine Zugriffsrolle an, benannt nach Modul und Rolle, zum Beispiel Leihgeräte – Geräteverwaltung. Die Rolle gehört zur Installation, und niemand hat sie außer den Personen, die Sie im Dialog gewählt haben. Die Rechte des Moduls stehen im Rolleneditor wie alle anderen Rechte.
• KI-Assistent. Bringt das Paket Anweisungen für den Assistenten mit, legt nexxus einen firmenweiten Skill an, der immer aktiv ist und nach dem Modul heißt, zum Beispiel Leihgeräte: Arbeitsweise. Solange das Modul deaktiviert ist, ist auch der Skill aus. Beim Deinstallieren verschwindet er. Avatare und Skills aus dem Paket werden firmenweite Avatare und Skills, ihre KI-Knöpfe erscheinen auf den Datensatzseiten des Pakets. Sie sind aus, solange das Modul deaktiviert ist; beim Deinstallieren verschwinden die Skills, und die Avatare werden archiviert, damit ihre Gespräche bleiben. Die Werkzeuge des Pakets stehen im KI-Assistenten allen zur Verfügung, die die passenden Rechte haben.
• Daten. Paketdaten aus data/ legt nexxus immer an, Beispieldaten aus demo/ nur mit gesetztem Haken. Dokumente aus den Beispieldaten landen in einem neuen Ordner in den Dateien, benannt nach dem Modul mit dem Zusatz „(Beispieldaten)“. Partner, die in Beispieldaten vorkommen, sucht nexxus über den Namen oder legt sie an.
• Dienstkonto. Jede Installation bekommt ein Dienstkonto, mit dem sich niemand anmelden kann, mit einer Systemrolle <Modulname> – Dienstkonto und allen Rechten des Moduls. Nur die externen Dienste des Pakets handeln damit. Pakete ohne Dienste nutzen es nie.
• Dienste. Bringt das Paket externe Dienste mit, benachrichtigt nexxus jeden davon über die Installation, sobald die Transaktion abgeschlossen ist.

Einstellungen und Ereigniszustellungen

Manche Pakete haben Einstellungen je Installation, zum Beispiel das Bundesland, dessen Feiertage zählen. Nach der Installation erscheint dafür auf der Paketseite die Karte Einstellungen mit den Feldern, die das Paket festlegt, etwa einer Auswahlliste und einer Zahl. Ändern Sie die Werte und klicken Sie auf Speichern, oder auf Verwerfen, um Ihre Änderungen zurückzunehmen. nexxus antwortet mit Einstellungen gespeichert. oder Nicht gespeichert: und dem Grund.

Pakete mit externen Diensten bekommen die Karte Ereigniszustellungen: Die letzten 100 Ereignisse, die NEXXUS an die Dienste des Pakets geschickt hat. Jede Zeile zeigt das Ereignis, die Nummer des Datensatzes, den Zustand Wartet, Zugestellt oder Fehlgeschlagen, die Zahl der Versuche, den letzten Fehler und wann das Ereignis entstanden ist. Solange Sie die Karte ansehen, aktualisiert sie sich alle fünf Sekunden. Aktualisieren lädt sie sofort neu. Wie Zustellung und Wiederholung funktionieren, erklärt Moduldienste.

Einstellungen gelten für diese Installation; die Felder legt das Paket fest.

Auf eine neue Version aktualisieren

Eine neue Version kommt als neue .nxm-Datei mit höherer Versionsnummer.

1. Laden Sie die neue Datei auf dem Reiter Pakete hoch. Der Katalog zeigt neben der installierten Version den Chip Update auf 1.1.0, und der Filter Updates listet jedes Paket mit einer neueren Version.

2. Öffnen Sie das Paket und klicken Sie auf Auf 1.1.0 aktualisieren. Die Schaltfläche aktualisiert immer auf die Version, die die Seite gerade zeigt. Eine andere Version wählen Sie mit den Schaltflächen neben Version.

   /modules/pakete/acme.leihgeraete?version=1.1.0

   

   Die Schaltfläche aktualisiert immer auf die angezeigte Version.

3. Lesen Sie den Dialog Leihgeräte aktualisieren mit der Unterzeile Von 1.0.0 auf 1.1.0:

   • Was sich ändert: jeder Changelog-Abschnitt zwischen der installierten und der neuen Version.
   • Datenanpassungen: Probelauf auf den heutigen Daten. Alle Schritte laufen in einem Zug; scheitert einer, bleibt das Paket auf 1.0.0. Je Migrationsschritt eine Zeile mit Schritt, Feld, Version, vor dem Wechsel oder nach dem Wechsel und der Zahl der Datensätze, die er ändern würde. Ohne Schritte: Keine Datenanpassungen nötig.
   • Neu zuzustimmen: nur das, was die neue Version über Ihre frühere Zustimmung hinaus nutzen will. Diese Version will zusätzlich Folgendes nutzen. Ohne Ihre Zustimmung bleibt das Paket auf 1.0.0. Haken Sie jeden Punkt an.
   • Neue Beispieldaten anlegen: nur, wenn die neue Version Beispieldaten mitbringt, die es hier noch nicht gibt. Der Hinweis darunter nennt ihre Zahl und endet mit Gelöschte Beispieldaten kommen nicht zurück. Der Haken ist zu Beginn nicht gesetzt. Lassen Sie ihn in produktiven Mandanten weg.
   • Diese Aktualisierung ist nicht möglich: nennt Gründe, die das Aktualisieren verhindern.

   

   Der Probelauf zählt die Datensätze, die jeder Migrationsschritt ändert.

4. Klicken Sie auf Aktualisieren. Der Hinweis lautet Leihgeräte ist auf 1.1.0 aktualisiert.

Das Aktualisieren läuft je Mandant in einer Transaktion. Scheitert ein Migrationsschritt, ändert sich nichts, und das Modul bleibt auf der alten Version. Die Rollen der Installation bekommen nur Rechte, die in dieser Version neu sind, und nur Rollen, die es vorher schon gab. Rechte, die Sie einer Rolle entzogen haben, bleiben entzogen. Versionsregeln und Migrationsschritte erklärt Daten und Aktualisierungen.

Eine ausgelieferte Version ändert sich nie

nexxus behält jede hochgeladene Version. Laden Sie denselben Schlüssel in derselben Version mit gleichem Inhalt noch einmal hoch, bekommen Sie das gespeicherte Paket zurück. Mit anderem Inhalt lehnt nexxus ab. Selbst ein korrigierter Tippfehler in einer Ansicht braucht eine neue Versionsnummer.

Deaktivieren und aktivieren

Deaktivieren blendet ein Modul aus, ohne seine Daten anzufassen. Klicken Sie auf der Paketseite auf Deaktivieren. nexxus fragt Leihgeräte deaktivieren?: Menüeinträge, Seiten und Werkzeuge des Pakets verschwinden für alle. Daten, Rollen und Einstellungen bleiben; „Aktivieren“ bringt alles zurück. Bestätigen Sie mit Deaktivieren. Der Hinweis lautet Leihgeräte ist deaktiviert.

Deaktivieren blendet das Modul aus und behält alle Daten.

Wer jetzt einen Link in das Modul öffnet, sieht die Seite Modul nicht verfügbar mit Das Modul „Leihgeräte“ ist deaktiviert. Die Adresse bleibt im Browser stehen, derselbe Link funktioniert also nach dem Aktivieren wieder. Mit Aktivieren kommt alles zurück: Leihgeräte ist wieder aktiv.

Deinstallieren

1. Öffnen Sie auf der Paketseite in der Aktionsleiste Weitere Aktionen und wählen Sie Deinstallieren. Der Dialog Leihgeräte deinstallieren öffnet sich.

2. Sichern Sie zuerst eine Kopie mit Daten exportieren (ZIP): Vorher sichern: eine JSON-Datei je Fachobjekt. Die Datei acme.leihgeraete-export.zip enthält je Fachobjekt eine <fachobjekt>.json mit jedem Datensatz samt Id, Schlüssel, Daten, Version und Zeitstempeln, dazu eine module.json mit Schlüssel, Version und Exportzeit.

3. Wählen Sie unter Was mit den Daten geschieht:

   • Daten behalten (voreingestellt): Das Paket verschwindet, die Datensätze bleiben unsichtbar erhalten. Eine spätere Installation bindet sie wieder an.
   • Daten löschen: Die Datensätze, die Rollen des Pakets und seine Beispieldokumente werden gelöscht.

4. Tippen Sie den Modulschlüssel in das Feld Zum Bestätigen den Schlüssel acme.leihgeraete eingeben. Die Schaltfläche Deinstallieren wird erst frei, wenn der Schlüssel stimmt.

5. Klicken Sie auf Deinstallieren. Der Hinweis lautet Leihgeräte ist deinstalliert.

   

   Erst der eingetippte Modulschlüssel gibt das Deinstallieren frei.

Nach Daten behalten zeigt der Katalog den Stand Entfernt, Daten behalten, und die Paketseite bietet Wieder installieren an. Der Dialog Leihgeräte wieder installieren sagt dann Die Daten der früheren Installation sind noch da und werden wieder angebunden. Rollen und Datensätze kommen zurück, wie sie waren.

Nach Daten löschen sind die Datensätze gelöscht, die Rollen des Pakets verlieren ihre Rechte und Zuweisungen, und die Beispieldokumente wandern in den Papierkorb der Dateien. Partner aus den Beispieldaten bleiben, weil andere Datensätze sie nutzen können. Das hochgeladene Paket bleibt im Katalog und lässt sich neu installieren.

Wenn etwas schiefgeht

Beim Hochladen zeigt der Katalog „<Datei>“ wurde nicht angenommen. und den Grund:

Meldung	Was zu tun ist
Das Paket ist fehlerhaft: mit einer Liste	Manifest oder Dateien verletzen die Paketregeln. Jede Zeile nennt Datei und Stelle, zum Beispiel module.json views.geraet.list: Filter 'notiz' ist nicht indexed. Beheben Sie jede Zeile und bauen Sie eine neue Datei.
Das Paket ist nicht signiert. Unsignierte Pakete sind für diesen Mandanten nicht zugelassen; zulassen lassen sie sich unter System › Module › Herausgeber.	Signieren Sie das Paket, oder schalten Sie im Reiter Herausgeber Unsignierte Pakete zulassen ein, wenn Sie der Quelle vertrauen.
Das Paket nennt den öffentlichen Schlüssel zu 'acme-2026' nicht, und die Plattform kennt ihn nicht; mit module-package.mjs build neu signieren. ...	Das Paket stammt von einer älteren Version des Skripts, die den öffentlichen Schlüssel noch nicht hineingeschrieben hat. Bauen und signieren Sie es neu.
Der Schlüssel, mit dem das Paket signiert ist, wurde für diesen Mandanten entfernt (...).	Ein Administrator hat den Schlüssel im Reiter Herausgeber entfernt. War das ein Versehen, vertrauen Sie ihm dort wieder.
Die Signatur mit dem Schlüssel 'acme-2026' ist ungültig.	Nach dem Signieren hat sich eine Datei geändert, oder ein anderer Schlüssel hat signiert. Bauen und signieren Sie neu aus dem unveränderten Ordner.
MANIFEST.sha256 stimmt nicht: mit Pfaden	Nach dem Bauen wurden Dateien ergänzt, entfernt oder bearbeitet. Bauen Sie neu.
acme.leihgeraete 1.0.0 gibt es schon mit anderem Inhalt; eine neue Fassung braucht eine neue Versionsnummer.	Geben Sie der Änderung eine neue Versionsnummer.
Das Archiv enthält kein module.json.	Das Manifest liegt weder ganz oben im Archiv noch in einem einzigen obersten Ordner.
Das Archiv ist entpackt größer als 64 MB. / Das Archiv hat mehr als 2000 Dateien.	Ein Paket darf entpackt höchstens 64 MB groß sein und höchstens 2000 Dateien haben. Jede Ansichtsdatei darf höchstens 2 MB groß sein.

Im Dialog zum Installieren oder Aktualisieren sperren Gründe im roten Kasten die Aktion:

Meldung	Was zu tun ist
Dem Herausgeber „acme“ vertraut dieser Mandant noch nicht (...).	Vergleichen Sie den Fingerabdruck und vertrauen Sie dem Herausgeber, siehe Dem Herausgeber vertrauen.
Der Schlüssel des Herausgebers „acme“ wurde für diesen Mandanten entfernt (...); damit signierte Versionen lassen sich nicht installieren.	Vertrauen Sie dem Schlüssel im Reiter Herausgeber wieder, oder fragen Sie den Herausgeber nach einer Version mit einem Schlüssel, dem Sie vertrauen.
Die Version ist nicht signiert, und unsignierte Pakete sind für diesen Mandanten nicht zugelassen (System › Module › Herausgeber).	Schalten Sie Unsignierte Pakete zulassen ein, oder fragen Sie nach einer signierten Version.
Version 1.0.0 verlangt die Plattform >=0.2.0 <1.0.0, hier läuft <Version>.	Das Paket ist für andere nexxus-Versionen gebaut. Fragen Sie den Herausgeber nach einer passenden Version.
Das Modul 'partners' gibt es auf dieser Plattform nicht.	Ein vorausgesetztes eingebautes Modul fehlt in dieser Instanz.
Das Modul 'partners' läuft in Version 1.0.0, verlangt ist >=2.0.0.	Das Paket braucht eine andere Version eines eingebauten Moduls. Fragen Sie den Herausgeber nach einer passenden Version.
Diese Version baut auf dem Paket 'muster.akten' auf. Pakete bauen nicht mehr aufeinander auf; was zusammengehört, kommt als ein Paket.	Die Version wurde hochgeladen, bevor Pakete in sich geschlossen sein mussten. Fragen Sie den Herausgeber nach einer Version, die alles in einem Paket mitbringt.
Das neue Pflichtfeld 'geraet.standort' hat keinen Standardwert.	Die neue Version verletzt eine Versionsregel. Beheben kann das nur der Herausgeber, mit einer neuen Version.
Die Migration auf 1.1.0 ist gescheitert, 'acme.leihgeraete' bleibt auf 1.0.0: mit der Ursache	Ein Migrationsschritt ist an Ihren Daten gescheitert. Es hat sich nichts geändert. Schicken Sie die Meldung an den Herausgeber.

In der Karte Einstellungen: Nicht gespeichert: Die Einstellungen sind ungültig. Prüfen Sie die markierten Felder im Formular.

Fehler, die externe Dienste melden, stehen unter Moduldienste.

Wie es weitergeht

Daten und AktualisierungenVersionsregeln, Migrationsschritte und was mit den Daten passiert.

RollenGeben Sie Personen die Rollen, die ein Paket angelegt hat.

Fallstudie: CuriaOSEin Paket für eine Kanzlei, mit Rollen, Zustimmung und einem Fristendienst.