Moritz

Ne, du meinst jetzt vom WP-Artikel zu dem externen Artikel; der Link funzt bzw. im WP kann man das Ziel einstellen. Es ging mir aber um die Verlinkung aus dem Forum in die Stories. Da kann man es nicht einstellen und es ist (bei mir!) kein konsistentes Verhalten beobachtbar.

Und bei mir nicht; wenn ich im Forum eine Story anklicke, geht manchmal der Artikel im gleichen Tab auf, manchmal wird ein neuer geöffnet. Ich versuche mal, drauf zu achten, wo welcher Vorgang auftritt und gucke dann auch gleich immer in den Quellcode, ob ich dort ein [target="_blank"] oder ähnliches finde...

Genial, @Britta Köhler, I love it! 😍 Für die ganz Interessierten unter euch hier noch der zugehörige Eintrag in unserer Produktdokumentation. So ist zum Beispiel zu beachten, dass eine Checkbox niemals den Wert "false" für NOTEMPTY() zurückliefern kann. (In diesem Fall einfach direkt den Wert der Checkbox abfragen.) Wichtig zu wissen ist übrigens, dass diese Formel auch mit Datensatzauswahlbausteinen (DSAB) funktioniert: Sobald ein Eintrag ausgewählt wurde, evaluiert NOTEMPTY({DSAB}) zu "true".

Sweet, genau das: Inspiration, Austausch, Hilfe, Hilfe zur Selbsthilfe (z.B. Tutorials). Haltet euch fest, wir kommeeeeeeeeeeeeeeeeeeeeeeeeen! 💥

@Christian Meixner und @Matthias Martin: Wenn ich hier im Beitrag auf den Link "Zum Artikel" klicke, öffnet sich der Artikel im gleichen Fenster. Bei allen anderen Dailies ist das anders (dort in neuem Tab). Ich finde aber im Editor keine Einstellungsmöglichkeit, das anzupassen. Könnt ihr mir weiterhelfen?

Hilfreich und nutzlich, muchas gracias! 💪 (Kleiner Randhinweis: Wer eine echte fortlaufende Nummer benötigt, auch derartiges haben wir für Kunden gelöst. Allerdings braucht es dann eine externe Datenanbindung. Bei Interesse einfach eine Nachricht an mich.)

Genial, was 1 geiler Beitrag! 😂 @Dirk Battermann wenn du mal jemanden zum Flexen suchst: meine Akkus sind stets geladen! @Johanna Becker interessanter Impuls, das ganze in Richtung Dialog mit Tabu-Charakter zu erweitern. Wäre dann halt eine ganz andere Ausrichtung, klingt aber auch spannend ("kann ich auch beides haben?" 😜)... Und herrlich auch dein "nice!" ganz am Ende, @Hannah Frick. Made my Friday! ✌️

Uhh yeah, Formel-Magic, I love it! 💙😃

Guter Ratgeber, danke! (Ich würde ihn mir gerne ausdrucken und an den Screen hängen, aber ihr wisst ja: papierloses Büro und so! 😉 Ne Spass beiseite, auf jeden Fall mal gebookmarked!) Den Tipp mit dem Einsprechen per Siri & Co. finde ich gut. Aber Achtung, in dem Fall unbedingt nochmal proof readen, bevor ihr den Artikel absendet. Da kommen nämlich mitunter komische Ergebnisse raus 😅

Mit den regulären API-Routen für den Abruf von Datensätzen kann ich zwar Datensätze für unterschiedliche Versionen abrufen (und damit auch einen gewissen Zeitraum eingrenzen). Möchte ich aber gezielt Datensätzen innerhalb bestimmter Zeiträume abrufen, helfen die Standardrouten hier nicht. Genau für diesen Fall gibt es in der sogenannten Preview-API aber die Möglichkeit, nach Datumswerten zu filtern und damit die Suche gleich auf spezifizierbare Zeiträume zu beschränken. Aber wie genau geht das? Zunächst einmal ist es erforderlich, dass wir uns für einen Datumswert entscheiden, denn ein Datensatz hat verschiedene Zeitstempel, nach denen wir filtern können (es kann auch nach mehreren, unterschiedlichen Zeitstempeln gleichzeitig gefiltert werden): clientCreatedDate ist der Zeitpunkt, zu dem der Entwurf vom User auf dem Endgerät geöffnet wurde sendDate ist der Zeitpunkt, zu dem der Datensatz vom User abgesendet wurde recievedDate ist der Zeitpunkt, zu dem der Datensatz an den smapOne-Servern empfangen wurde completedDate ist der Zeitpunkt, zu dem der Datensatz von den smapOne-Servern verarbeitet wurde (Daten gespeichert, alle Assets hochgeladen etc.) lastExportDate zeigt den Zeitpunkt an, zu dem der Datensatz exportiert wurde (sofern er auch schon exportiert wurde, sonst null) Und in der Preview-API kann ich nun nach Datensätzen suchen und hierbei den Zeitraum definieren, in dem die Datensätze liegen. Zum Beispiel im folgenden Fall einfach und simpel alle Datensätze, die nach dem 10. November um 11:05 Uhr (UTC) an der Plattform angekommen ("received") wurden. "gt" steht in hierbei für "greater than", sinngemäß "später als": /Backend/preview/Smaps/{smapId}/Records?$filter=ReceivedDate gt 2020-11-10T11:05:00Z Mit Hilfe dieser Filtermöglichkeiten in den API-Routen der Preview-API können also sehr gezielt Metadaten von smap-Daten gefiltert werden - in diesem Fall nach Zeitstempeln. Aber auch weitere Filtermöglichkeiten sind vorhanden. Weitere Beispiele können direkt in der Preview-API eingesehen werden. zur Swagger-API-Dokumentation zur FAQ: "Wie wähle ich in der Swagger API-Dokumentation die Preview-API aus?" Falls ihr weitere Fragen zur Preview-API habt, haut sie gerne als Kommentare unter diesen Beitrag. Wenn es andersgeartete Fragen sind, macht gerne einen eigenen Beitrag hier im Forum auf.

Ich hatte in meiner Vergangenheit einige Gespräche, in denen smapOne-User den Wunsch äußerten, in einer smap erfasste Daten automatisch drucken zu können. Das geht natürlich über das hinaus, was smapOne als Produkt leisten kann. Denn die Datensätze liegen ja erstmal "nur" virtuell/digital und in der Cloud vor. Wie das dann jeweils in die physische lokale Hardware (= den Drucker) überführt wird, das ist dann ja sehr individuell und von der lokalen Situation abhängig. Mich würde einmal interessieren: Gibt es hier Anwender, die schon erfolgreich eine Umsetzung dieser Art realisieren konnten? Mir fielen hier einige Lösungsansätze ein, kann aber keine Erfahrungen dazu liefern. Deshalb hier einmal der Aufruf zum Austausch, so denn schon Lösungen erarbeitet wurden. Lösungsideen Automatische Ablage des PDFs (z.B. per PowerAutomate, Zapier etc. in OneDrive) auf ein Netzlaufwerk, in dem ein Dienst/Script die ganze Zeit nach neuen Dokumenten scannt und bei Vorhandensein an den Drucker gibt. Drucker, die eine eigene Emailadresse haben, an die ein PDF gesendet wird. Hierzu könnte dann die PDF-als-Email-senden-Funktionen (als smap-Funktion oder als Baustein) genutzt werden, in denen der Datensatz automatisch an den Drucker gesendet wird. "IoT-Drucker", die weitere Wege/Protokolle als nur PDF-per-E-Mail unterstützen (hier gibt es doch bestimmt schon interessante Ansätze; SFTP, SSH, REST-API, per WhatsApp 😉 usw.). Haut mal rein, falls ihr da schon was umgesetzt habt oder wenn euch das Problem auch unter den Nägeln brennt oder wenn ihr mal über interessante Hardware oder sonstige Konzepte stolpert, die hier passen. Gracias!