Search the FirstSpirit Knowledge Base
Hallo zusammen,
wir prüfen aktuell, ob eine Integration des Omnichannel Managers über den CaaS in eine Salesforce Lightening Community möglich ist und sind dabei auf technische Hürden gestoßen.
Hautproblem ist, dass das snap.js CSS Objekte als eingebettete Blob-URIs nachlädt und dies offensichtlich zumindest aktuell nicht von den Salesforce CSPs unterstützt wird.
The CSP Trusted Sites configuration of Salesforce does not accept just blob: as a trusted site URL. So the Blob support cannot be added like a usual external domain
Eine mögliche Lösung für das Problem, könnte sein, dass das von OCM benötigte CSS über einen anderen Weg (z.B. externe URI) in die Salesforce Seite geladen wird. (z.B. per CMS Connect Funktion)
Wir fürchten darüber hinaus, dass es auch noch zu anderen Problemen kommen könnte, da Salesforce seine Inhalte/Komponenten sehr stark kapselt und man bestimmte DOM-Elemente nicht nach belieben abfragen o. manipulieren kann. Das müsste wir aber noch genauer verifizieren.
Leider sind wir da bei Salesforce nicht so flexibel wie bei einer selbst entwickelten Webanwendung, daher wäre die Frage wie flexibel das snap.js auf solche spezifischen Sicherheitsanforderungen noch angepasst werden kann und ob wir auf Grund dieser Einschränkungen erst einmal auf den OCM/TPP im Zusammenspiel mit Salesforce Community bei der weiteren Planung verzichten müssen.
Im Anhang befinden sich noch weitere technische Details unserer Analysen.
Leider überschreibt das JavaScript der Salesforce Lightning Community die Funktionen von "document", so dass diese keine Ergebnisse liefern für document.querySelectorAll('[data-preview-id]'). Damit findet die von uns mitgelieferten Funktion "Absatz-Verschieben" keine Verschiebe-Ziele und ist deaktiv.
astember Kannst du das hier dann als "gelöst" kennzeichnen?
Zu dem anderen Problem: Den Fix für OCM-368 liefern wir dann wahrscheinlich mit der nächsten Freigabe aus.
Hallo Andre,
wir evaluieren gerade, ob wir da etwas auf unserer Seite ändern können.
Gibt es denn nach dem Content Security Policy Fehler Folgefehler, die mit dem CSS zusammenhängen? Wenn nicht, könntest du zwischenzeitlich versuchen, das CSS manuell bereitzustellen und so weitere Tests durchführen. Ein zip mit CSS und den Bildern habe ich dir dafür hier abgelegt: http://docs.e-spirit.com/tpp/fs-tpp-css.zip
Eine kurze Rückmeldung dazu wäre gut.
LG, Peter
Hallo Peter,
ich habe das CSS + Bilder mal über die CMS-Connect Funktion von Salesforce eingebunden. Damit bin ich schon mal einen Schritt weiter und die Bearbeitungs-Widgets und Formulare sind im ContentCreator OCM schon mal sichtbar und können auch bedient werden. Der nächste Schritt wäre jetzt noch der Test mit Inhalten aus der Preview-CaaS Instanz. Wenn das auch funktioniert wäre es denke ich ein sinnvoller Workaround das CSS + Grafiken von snap.js getrennt vom Javascript einzubinden.
Super das es funktioniert hat! Und danke für die prompte Rückmeldung hier.
Halt uns ruhig weiter auf dem Laufenden hier. Ich hab die Prio für die Suche nach einer besseren Lösung für das Content-Security-Policy aber jetzt erst mal wieder etwas runtergestuft.
Bisher verliefen meine Tests mit dem Preview und Live CaaS weitestgehend positiv. Das Anlegen, Bearbeiten und Löschen von FirstSpirit Absätzen funktioniert bereits korrekt. Mir ist es bisher nur noch nicht gelungen die Standard-Arbeitsabläufe in unserer CaaS Implementierung zu aktivieren. Ich vermute, dass hier ggf. noch etwas in der CaaS Implementierung fehlt:
Hier die Beispielimplementierung per Preview-CaaS:
https://devgew1-demoshop.cs84.force.com/example/s/cms
Wäre schön wenn ich noch ein Tipp für das Troubleshooting der Workflows bekommen könnte. Das Modul BasicWorkflows sollte im Projekt korrekt konfiguriert sein.
Hallo Andre,
der Kontext für den Workflow-Button im CC-Rahmen wird über setPreviewElement() gesetzt. Ruft ihr das auf?
Ansonsten sollte bei den Workflows nur der Standard-Lösch-Workflow in den Projekteinstellungen eingestellt werden. Mehr ist an Konfiguration nicht nötig.
LG
Hallo Andre,
wir haben mit dem Ticket OCM-361 das Packaging verändert, so dass das CSS nicht mehr als Blob geladen, sondern im Header inlined wird. Der Fix wird im nächsten Release v1.2.15 enthalten sein, was wir hoffentlich Mitte/Ende nächster Woche bereitstellen können.
Beste Grüße
Christian
Das klingt nachdem was ich gesucht habe. Wir versuchen dies mal an der richtigen Stelle einzubinden.
Die Zuordnung des Workflow-Status zur Seite hatte ja über die Funktion setPreviewElement() funktioniert.
Ich hatte gehofft, dass über die richtige Zuordnung auch das Verschieben der Absätze funktioniert. Leider ist die Funktion nach wie vor ausgegraut. Ich vermute es könnte daran liegen, dass die Seite 2 Inhaltsbereich ("content_top" + "content_bottom") enthält. Wie kann man SNAP den korrekten Inhaltsbereich für die Zuordnung der Absätze "mitgeben"? Aktuell liegen die Absätze als <section>-HTML-Elemente inklusive Absatz-Preview-ID innerhalb eines einzelnen DIV-Containers mit der entsprechenden Seiten-PreviewID.
Die Verschiebe-Aktion benötigt ein umschließendes div mit der previewId des Body-Bereichs, wenn das Template mehr als einen Body-Bereich hat.
Könnt ihr das ausprobieren?