Jump to content

Absenden des Datensatzes in der Smap verhindern (verstecktes Pflichtfeld)


Jan Pietsch
Go to solution Solved by Jan Pietsch,

Recommended Posts

  • Solution

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.

 

allowed.png.90ae83a1c58f7f775bf6fc9ca013319f.png

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

 

blocked.png.d9332ce8c648646fbebc9bb40b6cd19e.png

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:

image.png.b36c66bbb68e928e18fe2f1cc46cec58.png

 

1e+308 (hohe_zahl)

image.png.cb7fff073824440a4e87a3a94ee61d2b.png

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

                                                                                                 

Mul (ResultNumber)

image.png.c8c046c6c8946c2bd2616b8576eea81a.png

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 by Jan Pietsch
  • Like 13
  • Thanks 5
Link to comment
Share on other sites

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? 

  • Like 6
Link to comment
Share on other sites

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 😘

 

  • Like 3
Link to comment
Share on other sites

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...) 💪

  • Like 2
Link to comment
Share on other sites

  • _Moritz_ pinned this topic
  • 11 months later...

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

  • Like 9
Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...