signova-spike

SIGNIDENT – Outlook Add-in (Spike)

Statisches Add-in für Outlook (Desktop/Web/Mobile), gehostet über GitHub Pages (https://uvaree.github.io/signova-spike/). Setzt beim Verfassen automatisch die zentral verwaltete E-Mail-Signatur aus signova-app – tenant-nativ, routet nie E-Mails, kennt nur Vorlagen- und Verzeichnisdaten.

Datei Zweck
manifest.xml Add-in-Manifest (Unified Manifest v1.1-Overrides). GUID 7f2a9c40-… niemals ändern – jede Aktualisierung über die <Version>.
launchevent.js Event-Handler + Signatur-Aufbau (Desktop/Web und Mobile teilen sich denselben Code, s.u.).
commands.html Minimale Runtime-Seite, lädt office.js + launchevent.js – der <SourceLocation> jedes LaunchEvent-Extension-Points.
taskpane.html Panel „Meine Signaturen” (manueller Weg, Signatur wählen).

iOS-/Android-Automatik (Mini-Auftrag, 16.09.2026)

Automatische Signatur beim Verfassen funktionierte bisher nur in OWA und Outlook Desktop (OnNewMessageCompose-Ereignis). In Outlook für iOS/Android war das Add-in zwar installiert und aktivierbar, aber die Automatik zündete nicht – dem Manifest fehlte die Mobile-Deklaration des Ereignisses (Referenz: learn.microsoft.com – Mobile event-based activation).

Geändert für manifest.xml (Version 1.1.0.0 → 1.2.0.0, GUID unverändert):

Geändert für launchevent.js:

Manifest-Regression 1.2.x + Lade-Ping (18.09.2026)

Mit 1.1.0.0 zündete OnNewMessageCompose nachweislich in OWA. Seit 1.2.0.0/1.2.1.0 zündete es nirgends mehr – weder OWA (InPrivate getestet, Panel lief, launchevent.js lud sichtbar) noch iOS. Taskpane/Panel funktionierten überall, also wurde VersionOverrides geparst – nur die LaunchEvent-Aktivierung war beschädigt.

Ursache: Die Mini-Auftrag-Änderung “iOS-Automatik” senkte die globale <Requirements>-Mindestversion (Top-Level und bt:Sets DefaultMinVersion in den V1.1-Overrides) von 1.10 auf 1.5, mit der Begründung, 1.5 sei “die von Microsoft dokumentierte Mindestanforderung für event-basierte Aktivierung überhaupt”. Das stimmt nicht für OnNewMessageCompose auf Web/Desktop: Microsoft dokumentiert explizit Requirement-Set 1.10 als Minimum, damit dieses Ereignis dort überhaupt erkannt wird (“Support for this feature in Outlook was introduced in requirement set 1.10” – Abschnitt “Outlook events”). 1.5 ist nur die Grenze, bis zu der Outlook Mobile sich selbst als API-fähig meldet (separat dokumentiert unter mobile-event-based), nicht die Mindestanforderung des Ereignisses selbst. Mit MinVersion="1.5" deklariert, hat Outlook Web/Desktop das LaunchEvent-ExtensionPoint schlicht nicht mehr als unterstützt erkannt – die anderen Diff-Teile derselben Pakete (Mobile-Icon-Resids) betreffen ausschließlich <MobileFormFactor> und können OWA gar nicht berühren, was die Fehlersuche eingrenzte.

Fix (manifest.xml, 1.2.1.0 → 1.2.2.0, GUID unverändert):

Lade-Ping (launchevent.js, SIGNOVA_VERSION 1.4.1 → 1.4.2): Ganz am Dateianfang (direkt nach SIGNOVA_BASE/SIGNOVA_TOKEN/SIGNOVA_VERSION, vor jeder sonstigen Logik) sendet die Datei jetzt einen Fire-and-forget-Ping (navigator.sendBeacon, sonst fetch(…, {keepalive: true}), in try/catch, kein Office-Objekt vorausgesetzt) mit Marker script_loaded an den bestehenden /api/addin/ping-Endpunkt der signova-app. Ein zweiter Ping mit Marker handler_invoked läuft am Anfang von onNewMessageComposeHandler. Damit lässt sich künftig aus den Server-Logs unterscheiden: “Skript lädt gar nicht” vs. “Skript lädt, aber das Ereignis kommt nie an” vs. “Ereignis kommt an, aber signovaApply scheitert” – genau die Unterscheidung, die in diesem Regressionsfall zuerst händisch (InPrivate-Test, Screenshot) gemacht werden musste.

Der bestehende /ping-Endpoint verlangte bisher zwingend email (Zod- Schema zPing, siehe signova-app); die Lade-Ping-Marker kennen zum Zeitpunkt script_loaded noch kein Office-Profil. Dafür ein kleiner, separater Fix in signova-app (eigener Commit dort): email in zPing optional gemacht, marker/userAgent als neue optionale Felder ergänzt; Anfragen mit gesetztem marker werden nur geloggt (kein Insert in signature_events – dieser Tabelle liegt eine strikte CHECK-Constraint auf mode IN ('auto','button') zugrunde, und sie speist die Abdeckungs-Statistik im Admin-Bereich; Lade-Ping-Marker dort mit einzumischen hätte diese Zahlen verfälscht). Bestehende Pings mit email laufen unverändert über den alten Pfad inklusive Insert.

Validierung

npx office-addin-manifest validate manifest.xml

Mobile-Icons korrigiert (Mini-Auftrag, 16.09.2026)

Formalie aus dem Manifest-Review zu 1.2.0.0: Im <MobileFormFactor>- Icon-Block referenzierten die 25er- und 48er-Slots die 16er- bzw. 80er- Bilddateien (Icon.16x16, Icon.80x80) statt eigener, passend skalierter Icons.

Geändert für manifest.xml (Version 1.2.0.0 → 1.2.1.0, GUID unverändert):

Validierung

npx office-addin-manifest validate manifest.xml

Deploy

Statisches Hosting über GitHub Pages – ein Push auf main ist der Deploy. Danach im Microsoft 365 Admin Center (zentral verteiltes Add-in) ggf. die Manifest-Version erneut synchronisieren lassen, falls der Tenant nicht automatisch auf die neue <Version> reagiert.