Nicht editierbare Eingabefelder

[Philip Alvermann]

Wir haben das Thema schon voriges Jahr angefragt, und es ist uns immer noch wichtig.

Gewünscht ist eine Funktion die verhindert das ein Feld vom Anwender bearbeitet werden kann.
In einer Aufgabe wird ein Feld, Text oder Zahlenwert, vorbelegt und soll natürlich auch so mit dem Inhalt, auf dem Report erscheinen. Der Anwender soll keine Möglichkeit haben den Wert zu ändern.

Ein Haken wie für Pflichtfeld sollte ja im Grunde reichen, wenn das Feld gar nicht benötigt wird kann es ja immer noch über die Aktivierung ausgeblendet werden.
Pflichtfeld und Editierbar sollten sich nicht behindern.

Das Feld sollte auch über die Rest-API entsprechend eingestellt werden können.

[Michael Prem]

Diese Funktion könnte auch unter Umständen genützt werden, um ein Feld nach der Eingabe zu sperren, wenn es nicht vorbelegt ist 🙂

[Philip Alvermann]

Gibt es hier schon etwas neues, ist was in der Planung?

[Marika Karl]

Hallo @Philip Alvermann und @Michael Prem. Leider kann ich noch keine frohe Kunde übermitteln, was die Planung dieses Features angeht. 

Nicht editierbare bzw. gesperrte Eingabefelder, evtl sogar ganze Bereiche, sind Teil unserer Überlegungen zu einem predefined task flow und damit absolut auf unserem Radar. Ich lese raus, dass schon die kleinste Einheit dazu, ein simples Häkchen, das ein Eingabefeld sperrt, Hilfe bringt. Das macht mich schon ein bisschen glücklich, weil wir dann, wenn wir den task flow angehen, schon mit kleinen Iterationen des Ganzen euch endlich entgegen kommen können. 

Bitte haltet durch und seid euch gewiss: wir streben es an!

Viele Grüße
Marika

[Moritz]

FYI: Hier ein weiterer Fall für diesen Featurewunsch

 

[Annemarie]

@Philip Alvermann Unabhänig von einer konkreten Lösungsidee verstehe ich dich so, dass in deinem Prozess Aufgaben per API erstellt werden, und dort Bausteine befüllt werden, die in weiteren Schritten nicht verändert werden sollen.

Unsere Featureidee mit den vordefinierten Prozessen und festlegbaren Bearbeitungsbereichen würde beinhalten, dass Daten, die in einem Schritt ausgefüllt werden, in späteren Schritten nicht mehr anpassbar sind. Das Anlegen einer Aufgabe wäre auch genau so ein Schritt, unabhängig davon, ob es manuell durch einen smap-User in der smap, oder als Alternative per API erfolgt, dennoch ist es dieselbe Aktion. Werte, die hier ausgefüllt werden, wären danach nicht mehr editierbar. 
Würde das dein Szenario abdecken? Was würdest du noch brauchen? 

[Philip Alvermann]

vor 15 Stunden schrieb Annemarie:

Unabhänig von einer konkreten Lösungsidee verstehe ich dich so, dass in deinem Prozess Aufgaben per API erstellt werden, und dort Bausteine befüllt werden, die in weiteren Schritten nicht verändert werden sollen.

Fast richtig, einige Felder die durch die Rest-Api befüllt werden sind auch nur Vorschläge und können sich unter Umständen auch bei der Bearbeitung der Aufgabe ändern.

Hier mal ein Beispiel was es eventuell deutlicher macht:

Ein Techniker fährt zu einem Service und hat dazu eine Aufgabe erhalten. Diese Aufgabe enthält unter anderem die Adresse, Kundennummer und Auftragsnummer, da diese auf dem Bericht angedruckt werden sollen ist das ein Baustein (Text, Zahl, etc.) der angedruckt werden kann.
Wenn der Techniker nun die Auftragsnummer ändert, kann dieser Bericht nicht mehr korrekt in unserem CRM System zugeordnet werden, auch der Kunde könnte das nicht mehr zuordnen da der bisherige Schriftverkehr ja über eine ganz andere Auftragsnummer lief.

So gibt es noch einige andere Felder wie z.B. Checkboxen für eine Anfahrtspauschale als Vorgabe aus dem CRM, welche angedruckt werden muss aber auch nicht verändert werden darf.

In anderen Fällen sollen Felder der Vorgabe durchaus angepasst werden können, wie zum Beispiel die Kilometer für die Anfahrt.

Die Rücklaufenden Werte, wie z.B. Anfahrt, Arbeitszeit, Material werden bei uns in das CRM zurückgespielt und dienen im Anschluss als Vorgabe für die Erstellung der Rechnung. 

Also ein alles oder nichts, wie bei eurer Featureidee würde uns nicht weiterhelfen.

[Bülent Erbas]

Den entsprechenden Bausteinen müssten lediglich eine weitere Eigenschaft  "Baustein darf nicht editiert werden" hinzugefügt werden, die optional auswählbar ist. Idealerweise ist der Flag auch über die API steuerbar.

 

[Philip Alvermann]

Am 14.11.2023 um 16:50 schrieb Annemarie:

Würde das dein Szenario abdecken? Was würdest du noch brauchen? 

 

Am 15.11.2023 um 08:44 schrieb Philip Alvermann:

Fast richtig, einige Felder die durch die Rest-Api befüllt werden sind auch nur Vorschläge und können sich unter Umständen auch bei der Bearbeitung der Aufgabe ändern.

Ich schiebe das mal wieder an. Fast ein Monat ist um und im Feature-Board habe ich dazu leider noch nichts passendes gefunden.

@Annemarie du wolltest Beispiele, die hatte ich geliefert. Leider ist mir nicht klar ob diese dir ausreichen.

[Annemarie]

@Philip Alvermann 
Deine Erklärung war auf jeden Fall hilfreich, danke dafür! Wir haben uns dazu intern noch einmal abgestimmt und sehen den Unterschied zwischen Szenarien, bei denen ganze Bereiche Bearbeitern zugeordnet und für andere gesperrt werden sollen, und Fällen, wo nicht alle Eingaben eines früheren Bearbeiters für spätere Bearbeiter gesperrt sein sollen, sondern sich das von Baustein zu Baustein unterscheidet.

Ihr findet die Idee jetzt auch auf unserem Board als "Schreibschutz für einzelne Bausteine nach Aufgaben-Weitergabe", damit sie dort separat betrachtet und kommentiert werden kann.

[Philip Alvermann]

Am 15.12.2023 um 14:27 schrieb Annemarie:

Ihr findet die Idee jetzt auch auf unserem Board als "Schreibschutz für einzelne Bausteine nach Aufgaben-Weitergabe", damit sie dort separat betrachtet und kommentiert werden kann.

Tausend Dank, das freut mich.

[Johannes Seelig]

Ich möchte das nun auch endlich haben. 
Es kann doch nun wirklich nicht so schwierig sein. Ergebnis-Bausteine können ja auch  (in der APP ) ausgeblendet werden, aber leider nicht per REST befüllt werden.

Zudem wäre es toll, den Telefonbaustein individuell befüllen zu können, damit der USER den jeweiligen Kunden anrufen kann. 
Wo liegt das Problem ?

[Annemarie]

@Johannes Seelig So interessant wir eurer Ideen finden, schaffen wir es leider nicht, jeden Bedarf direkt anzugehen. Wir haben die Erfahrung gemacht, dass es sich lohnt, einen Bedarf in Zusammenhang mit anderen Wünschen und umgebenden Funktionen zu betrachten, um für euch die beste Produkterweiterung zu liefern. In diesem Fall bestehen Zusammenhänge mit Erweiterungen zur Aufgabenfunktion, einem großen Themenblock mit einer Menge Potenzial, und mit anderen Ideen für Bausteine. Diesen wollen wir uns erst etwas später intensiv widmen. Im Moment stecken wir viel Energie in unsere neue Web-App, um die smap-Nutzung für euch auf das nächste Level zu bringen 🙂 .

[David Susami]

Warum nicht einfach ein DSAB mit den notwendigen Daten füllen und von dort sich die nicht editierbaren Eingaben entnehmen?

Gut ich kenne den konkreten Usecase nicht, jedoch wirkt es auf mich so als würde man etwas so nutzen wollen, wie es nicht Gedacht ist.

Man will ja auch kein unbeschreibbares Papier, sofern man überhaut auf toten Baum schreiben wollen würde.

[Bülent Erbas]

@David Susami
Es geht meistens um Situationen bei Aufgaben und / oder Daten die z.B. aus einer Datenbank kommen, bei denen Teile in der smap entsprechend vorausgefüllt sein sollen um den Benutzer mit qualitativ "sauberen" Daten auszustatten.

Aktuell lassen sich die vorausgefüllten Felder editieren, was wiederum, bei einer Änderung einen Abgleich zurück mit einer Datenbank erschwert, gar zum Fehler führen lässt.

Das ist schon eine sinnvolle Erweiterung.

[David Susami]

@Bülent Erbas

Verstehe.

Wäre ein wenig um ein paar Ecken Gedacht, aber mit einer DSAB und Textanzeigebaustein wäre es umsetzbar. Oder ist das zu unpraktisch?

[Bülent Erbas]

Ja, das geht schon... aber die Daten kommen nicht von einer DSAB.

Die kommen über die API Schnittstelle aus einer Datenbank und es werden aus dem Automatismus heraus Aufgaben generiert.
Einige Anforderungen lassen sich nicht mit einer DSAB umsetzen, da man z.B. die Live-Datenbank als führendes System heranziehen möchte.

[Johannes Seelig]

vor 1 Stunde schrieb David Susami:

@Bülent Erbas

Verstehe.

Wäre ein wenig um ein paar Ecken Gedacht, aber mit einer DSAB und Textanzeigebaustein wäre es umsetzbar. Oder ist das zu unpraktisch?

@David Susami
die Idee ist ja soweit nicht schlecht, aber wie blende ich DSAB aus ? sodass der USER den DS nicht löschen kann ?

-- Aus deinem Beispiel genommen --

 

Bearbeitet 14. Februar von Johannes Seelig

[Johannes Seelig]

vor 1 Stunde schrieb Bülent Erbas:

Ja, das geht schon... aber die Daten kommen nicht von einer DSAB.

Die kommen über die API Schnittstelle aus einer Datenbank und es werden aus dem Automatismus heraus Aufgaben generiert.
Einige Anforderungen lassen sich nicht mit einer DSAB umsetzen, da man z.B. die Live-Datenbank als führendes System heranziehen möchte.

@Bülent Erbas

 

Den DSAB kannst du problemlos per REST befüllen 
Du lädst eine leere EXCEL-Tabelle hoch, welche in der ersten Zeile die Feldnamen enthält ( die bleiben starr ) 
per Rest kannst du dann einen Datensatz mitschicken.

 

"data": {
    "Text": "TEST",
    "DataRecordSelect": {           << DER DSAB
      "TPLATZ": "Lorem Ipsum",      << DIE Feldnamen | Werte
      "FABRIKNR": "Lorem Ipsum",
      "WERK": "Lorem Ipsum",
      "HALLE": "Lorem Ipsum",
      "STRASSE": "Lorem Ipsum",
      "PLZ": "Lorem Ipsum",
      "ORT": "Lorem Ipsum",
      "UUID": "13245"
    }
  }

Bearbeitet 14. Februar von Johannes Seelig

[Johannes Seelig]

@Annemarie
Das ist ja eine nette Sache - Diese WEB-APP, nur erschließt sich mir hier tatsächlich nicht der Grund, wieso man aus einer OFFLINE-Anwendung, eine Online-Anwendung machen möchte 🤔
Der Hauptnutzen an SMAP ist doch, dass der Endnutzer die Anwendung / Formulare Offline ausfüllen kann... oder habe ich da was falsch verstanden ?

Unser Nutzen liegt jedenfalls in der Offline-Funktion, welche Betriebssystemübergreifend nutzbar ist ...
Eine Online-Datenbankanbindung / Webanbindung ist ja mit wenig Aufwand per PHP oder ähnlichem schnell umsetzbar. 
Deshalb solltet Ihr meines Erachtens mehr den Fokus auf die bereits bestehende Lösung richten.

Für so eine rudimentäre "Ausblendfunktion" wird es wohl keine 100 Entwickler benötigen, welche erstmal ein Jahr lang brainstroming betreiben müssen. 

 

Aber vielleicht liege ich ja auch komplett falsch.....

Bearbeitet 14. Februar von Johannes Seelig

[Bülent Erbas]

vor 27 Minuten schrieb Johannes Seelig:

Den DSAB kannst du problemlos per REST befüllen 
Du lädst eine leere EXCEL-Tabelle hoch, welche in der ersten Zeile die Feldnamen enthält ( die bleiben starr ) 
per Rest kannst du dann einen Datensatz mitschicken.

Natürlich, aber...

1. du hast zwei Schritte mehr und dadurch auch entsprechend Fehlerquellen mehr...  DB -> Excel -> smap -> Excel -> DB ? 
Wenn die Schnittstellen es nicht anders zulassen, wäre das natürlich ein Weg.
2. Beim DSAB musst du das Ergebnis immer auswählen... direkt über die API hast du Datensätze schon drin 😉

[Bülent Erbas]

vor 14 Minuten schrieb Johannes Seelig:

Das ist ja eine nette Sache - Diese WEB-APP, nur erschließt sich mir hier tatsächlich nicht der Grund, wieso man aus einer OFFLINE-Anwendung, eine Online-Anwendung machen möchte 🤔
Der Hauptnutzen an SMAP ist doch, dass der Endnutzer die Anwendung / Formulare Offline ausfüllen kann... oder habe ich da was falsch verstanden ?

Ich denke, die Anforderungen sind sehr vielfältig. Daher würde ich  nicht pauschal behaupten, es ist eine Offline-Anwendung.
Es werden Dienste in der Cloud zur Verfügung gestellt, per se ist es schon mal eine Online-Anwendung.
Das man aber nun die smap-App auch Offline einsetzen KANN, bietet es einen Mehrwert, den ihr auch scheinbar zu schätzen gelernt habt.
Aber irgendwann muss es dennoch online gehen, damit die erfassten Daten auch in die Cloud übertragen werden können. Daher auch keine reine Offline-Anwendung.

Bzgl. Web-App finde ich es eine sehr gelungene und konsequente Weiterentwicklung. 
Bei uns öffnen sich damit sehr viele Möglichkeiten.
- die Einbindung unserer Sachbearbeiter die aufgrund unserer IT-Infrastruktur und Security Compliance nicht die Chance hatten smaps unter Windows als Anwendung einsetzen zu können. -> Terminal Server. Somit können wir unsere Prozesse weiter optimieren
- die Einbindung unserer  Kunden ohne das sie eine App installieren oder anwenden müssen. Bisher immer eine Hemmschwelle.

 

[Johannes Seelig]

Also prinzipiell ist jedes Formular erstmal offline auf dem device - erst wenn es abgeschickt wird, wird es zur Cloud geladen.

Aber egal:

Der „Ausblenden“ Knopf wäre trotzdem sehr hilfreich.

zu diesem Punkt :

DB -> Excel -> smap -> Excel -> DB ? 

der Ansatz war ja, dass man den dsab als Quelle nutzen soll, was aber auch unsinnig ist, da der User den DSAB einsehen und löschen kann.

der Weg ist übrigens anders :

DSAB einmalig leer (nur Feldnamen) in der smap hinterlegen.

diesen per Rest-json befüllen und in den einzelnen Bausteinen das entsprechende Feld ausgeben.

das ganze kommt dann per Webhook zurück in die DB. Da gibt es keinen Zwischenschritt über excel. 

 

[Philip Alvermann]

All diese Krücken die hier genannt wurden helfen nicht weiter.

Beispiele warum das für uns ein Showstopper für diese Anwendung ist sind genannt.

Mir ist schon klar das alle Feature Wünsche die eine Anpassung der Bausteine und des Clients erfordern, erstmal auf hold gehen bis die Web App fertig ist.

Sicher gibt es auch noch andere Lösungen es muss ja nicht immer "NoCode" sein.

[David Susami]

vor 14 Stunden schrieb Johannes Seelig:

wie blende ich DSAB aus ?

@Johannes Seelig siehe Screenshot. Unter Berichtsvorlage "Baustein im Bericht nicht anzeigen" Falls es nicht angezeigt wird, solltest den "Expertenmodus" bei den Optionen im Smapeditor aktivieren.

War gestern nicht mehr im Büro, weshalb ich verzögert antworte. 

Bearbeitet 15. Februar von David Susami