Absenden des Datensatzes in der Smap verhindern (verstecktes Pflichtfeld)

[Jan Pietsch]

Hallo Zusammen,

im Folgendem soll darum gehen, wie man das Absenden von Datensätzen durch Regeln verhindern kann.

Das kann sehr hilfreich sein, wenn sichergestellt werden muss, dass die Daten bestimmte Regeln erfüllen - z. B. bei der Überprüfung, ob eine Datum in einem bestimmten Zeitfenster liegt, ob der richtige Datensatz ausgewählt wurde oder, ob eine Lesebestätigung wirklich angehakt ist.

 

Als Beispiel soll hier eine Checkbox dienen. Das Absenden soll nur möglich sein, wenn diese angehakt ist.

 

Hier ist die Checkbox angehakt - das Senden ist möglich.

 

Hier ist die Checkbox nicht angehakt - das Senden ist nicht erlaubt.

 

Um dies zu erreichen, nutzen wir die Obergrenze von Zahlengrößen in den Smaps aus. Wenn eine Zahl in einem versteckten Ergebnisfeld zu groß wird, kann der Datensatz nicht gesendet werden. Die größtmögliche Zahl liegt irgendwo bei 1e308 (eine Eins mit 308 Nullen). Wir müssen also eine Zahl berechnen, die oberhalb dieser Grenze liegt.

Im Designer sähe das wie folgt aus:

 

1e+308 (hohe_zahl)

Der Baustein 1e+308 enthält eben diesen Wert. 

                                                                                                 

Mul (ResultNumber)

Der Baustein MUL enthält eine Formel:

Wenn Checkbox (angehakt), dann wird 0 ausgegeben. Wenn nicht, dann soll die hohe Zahl (1e+308) mit sich selbst multipliziert werden.

IF({Checkbox},0,MUL({hohe_zahl},{hohe_zahl}))

Die Multiplikation verlässt an dieser Stelle den zulässigen Wertebereich und führt zu dem Fehler, der das Absenden verhindert.

Idealerweise wird dem Nutzer der Grund für das Sendeverbot in Form eines Hinweises vermittelt, um Frustration zu vermeiden.

 

                                                                                             

 

Viel Spaß beim Ausprobieren und viele Grüße

Jan Pietsch

Edited January 4, 2023 by Jan Pietsch

[Moritz Münzenmaier]

Das ist wirklich ein großartiger Workaround 😄 
Es klingt im ersten Moment total abstrakt, aber mir fallen auf Anhieb echt einige Teil-Szenarien ein, in denen das Sinn machen könnte in denen 

Endzeitpunkt in der smap liegt vor dem Startzeitpunkt in der Eingabe -> negativer Zeitwert -> Das verstecke Pflichtfeld mit der Mammutzahl verweigert das Absenden und ein Hinweis in der smap weist darauf hin. 

Die erfasste Arbeitszeit überschreitet einen gewissen Schwellwert -> Das verstecke Pflichtfeld mit der Mammutzahl verweigert das Absenden

Vielleicht hat ja jemand noch anderen Ideen für Plausibilitätsprüfungen, die man mit Einschränkungen in Zahleneingabefeldern oder Validierungsregeln in Textfeldern nicht abbilden kann? 

[_Moritz_]

Superstark, @Jan Pietsch, echt sehr geil. Ich liebe es, wie die Anwender die Grenzen, die die Developer mal ursprünglich gezogen haben, kennenlernen und auszuweiten wissen 😉

Dein Beispiel mit einer Pflicht-Checkbox hat mich übrigens auf die Idee gebracht, einen Artikel zu einer Pflicht-Checkbox zu verfassen, die im Zweifelsfall auch ohne deine Magie auskommt 😘

 

[_Moritz_]

Am 14.12.2022 um 09:11 schrieb Moritz Münzenmaier:

Vielleicht hat ja jemand noch anderen Ideen für Plausibilitätsprüfungen, die man mit Einschränkungen in Zahleneingabefeldern oder Validierungsregeln in Textfeldern nicht abbilden kann? 

Was ich auch gerne mache ist ein Texteingabefeld mit Daten aus anderen Bausteinen zu füttern und dann darauf eine Validierungsregel zu legen. Also quasi eine aggregierte Prüfung, nicht auf Basis der Einzelfelder. Aber das war ja nicht, wonach du gesucht hast. Insofern: Weitere Ideen fallen mir leider spontan nicht ein. In sofern megageil @Jan Pietsch, dass du derartige Dinge mal getestest hast (aber ist ja zugegebenermaßen auch ein Standardtest: teste die App mit besonders kleinen Zahlen, mit besonders großen Zahlen, mit 0, mit Buchstaben, wo Zahlen erwartet werden und vice versa...) 💪

[Ina Krüger]

Hallo zusammen,

danke für den Beitrag.
Ich hab die Checkbox in meinem Fall jetzt einfach weg gelassen und mit Aktivierungsregeln aggiert.
Ich prüfe auch das Datum und vergleiche es mit dem aktuellen Zeitstempel.
In unserem Fall senden wir Anträge für das Buchen von Unterkünften.
Im Fall das der Reisebeginn oder das Reiseende, was angegeben ist vor dem Zeitstempel liegt, lasse ich eine Meldung sowie die oben beschriebenen Felder im Hintergrund aktivieren.
So verpflichte/zwinge ich den Nutzer seine Daten nochmal auf Richtigkeit zu prüfen.

Danke Jan für deinen Beitrag.
Er war in diesem Fall für mich sehr hilfreich, ich wäre ehrlich gesagt nie darauf gekommen.
Ich denke auch das ich diese Prüfung sicherlich nochmal anderweitig einsetzen kann, wenn ich bereits vorhandene Smaps anpasse/überarbeite.

Vielleicht denkt Smap ja auch über eine Funktion "heute" nach, dann müsste man in meinem Fall nicht mehr mit einen gesetzten Zeitstempel arbeiten und die Fehlermeldung für den Nutzer käme direkt und nicht erst nach setzen des Stempels.

Vielen Dank.
Liebe Grüße

[Sven Leist]

Ich habe diese tolle Idee zur Plausibilisierung von Eingaben in meiner ersten App verwendet... funktioniert super. Vielen Dank an @Jan Pietsch  für diesen Idee.

Jetzt habe ich in der Datenstruktur aber auch solche Felder wie "hohe Zahl" bzw. die Felder, die ich zur Plausibilitätsprüfung erstelle ("Hohe Zahl * hohe Zahl"). Wenn ich mir diese Datenbank nach EXCEL ziehe, könnte ich diese dort eigentlich nicht benötigten Felder natürlich ausblenden/ignorieren... kann man aber ggf. die Erstellung dieser Felder in der Datenstruktur - analog zu den Berichten - vermeiden/steuern ?

 

[Manuel Rühl]

vor 16 Stunden schrieb Sven Leist:

Wenn ich mir diese Datenbank nach EXCEL ziehe

Was heißt das genau für dich? Über das Backend einfach einen Excel-Export oder per PowerQuery?

[Sven Leist]

Einfach ein Exel-Export! 

[HK alias Holger]

Den Standard Excel export kannst du nicht beeinflussen. Dazu müssest du die Datensätze manuell z.b. via Odata / API nach Excel ziehen. Da hat man dann mehr Möglichkeiten

[Sven Leist]

Danke.