/
Deep Link: Übergeordnetes System → Remote Master (remotemaster://)

Deep Link: Übergeordnetes System → Remote Master (remotemaster://)

Mit dem Custom URL Scheme remotemaster:// kann ein übergeordnetes System (z. B. die Odoo Barcode App) die Remote-Master-App per Barcode-Scan öffnen und die Ansicht direkt auf einen Kunden vorfiltern: ein Scan → der richtige Kunde → Prüfung starten. Umsetzung von RMF-1441 / RMA-4427 (Variante A, Custom URL Scheme). Seit 08.07.2026 in master gemerged (MR !154); ausgeliefert ist der MVP: customerId-only, siehe Abschnitt „Entscheidung: MVP ohne Token-Login".

URL-Schema

remotemaster://open?customerId=<Kundennummer>[&token=<token>]

Parameter

Parameter

Pflicht

Bedeutung

Parameter

Pflicht

Bedeutung

customerId

optional

Die Kundennummer des Kunden. Nach dem Login/Autologin wird die Ansicht auf diesen Kunden gefiltert. Das ist der MVP-Weg.

token

optional

Wird technisch unterstützt (SSO-Temp-Token-Flow), ist aber nicht Teil des MVP und für übergeordnete Systeme nicht praktikabel — siehe Abschnitt „Entscheidung: MVP ohne Token-Login".

nodeId

optional

Wird geparst, aber aktuell noch nicht ausgewertet (für spätere Nutzung).

Wichtig für die Integrator-Seite (z. B. Odoo): customerId muss die Kundennummer sein (in der DB TCustomer.customId, z. B. 10173 oder alphanumerisch KD-006216) — nicht die interne Datenbank-ID des Kunden. Die App löst die Kundennummer intern zur richtigen ID auf. Eine interne ID wird ebenfalls akzeptiert (exakter ID-Treffer hat Vorrang), aber übergeordnete Systeme kennen typischerweise nur die Kundennummer.

Verhalten des Kunden-Filters

Situation beim Kunden

Verhalten

Situation beim Kunden

Verhalten

Genau 1 Elementgruppe

Die Gruppe wird direkt geladen — der Techniker landet ohne weiteren Tap in den Prüflingen.

Mehrere Elementgruppen

Der Gruppen-Auswahldialog öffnet sich, der Techniker wählt die Gruppe.

Keine (lesbare) Elementgruppe

Kein Filter (No-op), kein Fehler.

Der Filter greift sowohl beim Cold Start (App war geschlossen) und nach einem Login als auch live, wenn der Link ankommt, während die App bereits geöffnet ist.

Plattform-Unterstützung

Android VERIFIZIERT iOS/iPad VERIFIZIERT

  • Android: Intent-Filter für Schema remotemaster in der AndroidManifest.xml.

  • iOS:CFBundleURLTypes mit Schema remotemaster in der Info.plist.

Deep Link auslösen / testen

  • QR-Code (Produktions- und Testweg): einen QR mit dem Inhalt remotemaster://open?customerId=<Kundennummer> erzeugen und mit der Geräte-Kamera scannen → „In Remote Master öffnen".

  • Android per adb (Test): adb shell am start -a android.intent.action.VIEW -d "remotemaster://open?customerId=10173"

  • iOS (Test): QR mit der Kamera scannen oder die URL in der Notizen-App antippen. Hinweis: generische QR-Scanner öffnen Custom Schemes teils nicht — Kamera-App oder Notizen verwenden. Auf Android für generische Scanner ggf. eine intent://-URL nutzen.

Entscheidung: MVP ohne Token-Login

  1. Ausgeliefert wird der MVP: customerId-only. Der Deep Link filtert die Ansicht, die Authentifizierung bleibt beim normalen App-Login (der Techniker muss eingeloggt sein bzw. der Autologin greift). Ein Token-basierter Auto-Login ist nicht Teil des MVP. (Stand 08.07.2026)

Warum: Der token-Parameter funktioniert technisch so, wie er implementiert ist — die Kette remotemaster://open?token=… → Route /login/<token> → PageLogin → ServiceAuth.authSSO() → sso_get_token ist durchgängig verdrahtet und loggt mit einem gültigen Token ein. Praktikabel ist das für ein übergeordnetes System aber nicht: Diese SSO-Temp-Token sind kurzlebig und entstehen ausschließlich aus einem interaktiven SSO-Browser-Login — genau das doppelte Login, das der Kunde vermeiden will, und per API nicht automatisiert ausstellbar. Ein von Odoo „vorab per API" erzeugter Cloud-API-Session-Token (so der Vorschlag des Kunden, Antwort Behmenburg vom 07.07.2026 in RMF-1441) wird vom sso_get_token-Pfad nicht akzeptiert — am 08.07.2026 lokal gegen den Server verifiziert: gültiger Session-Token aus /auth/validate an /auth/sso_get_token/<token> liefert {"id":"null","companyId":"null","token":"null","username":"null"}, die App bricht daraufhin mit CREDENTIALS-Fehler ab (der Session-Token selbst bleibt dabei gültig, keine Nebenwirkungen).

Ausblick (falls Token-Auto-Login später doch gewünscht): Entweder ein eigener Pfad token → /auth/validate für Cloud-API-Session-Token, oder OAuth/M365 (Vorschlag des Kunden — Odoo und Remote Master nutzen dort denselben M365-Login). Beides wäre ein eigenes Ticket mit Backend-Beteiligung.

Referenzen

  • Jira: RMF-1441 (Entwicklung), RMA-4427 (Kundenanfrage)

  • Merge Request: cloud/RemoteMasterFlutter!154

  • Implementierung: lib/services/service_deeplink.dart (ServiceDeeplink), lib/pages/page_home.dart

Hinweis für Entwickler: iOS-Builds für dieses Projekt immer mit fvm flutter (gepinnte Version) bauen, nicht mit einer neueren globalen Flutter-Version — sonst löst die UIScene-Migration aus und bricht den Build (FlutterImplicitEngineDelegate).