"X" zum Löschen eines Eintrags in 1:n Relation unterbinden?

Martin

Hallo,

folgender Fall: Zwei Relationen, "case" und "purchase". Einem case können 0..n purchases zugeordnet werden, jeder purchase muss einem case zugeordnet sein.

Also in der Relation purchase ein 1:n Attribut nach case, mandatory.

(Version 3.7, hab gerade erst die 3.8 Ankündigung gesehen)

Im Formular case mit der Anzeige eines cases möchte ich auch die zugehörigen purchases anzeigen:

Löschen habe ich dabei deaktiviert, und dennoch wird im Formular mir das "X" angezeigt, das wegen mandatory nicht funktionieren kann und nicht funktionieren soll.

Wo ist mein Fehler, wie bekomme ich das "X" da weg?

gabriel

Die Option "Löschen" für die Relation purchase sagt dem System, dass es Datensätze von purchase nicht löschen darf. Das Feld (F17) kann aber keine Datensätze löschen, es setzt nur das Beziehungsattribute zu case auf der purchase-Relation. Deswegen hat die Option hier keine Auswirkung.

Wenn du das "X" weghaben willst, musst das Feld auf "lesend" gestellt werden. Dann kannst du die Werte fürs Beziehungsattribut nicht mehr pflegen.

Das setzt aber voraus, dass du auch das Hinzufügen blocken möchtest. Wenn du möchtest, dass man nur noch neue purchases hinzufügen, aber keine mehr wegnehmen kann, müsste man mit Frontendfunktionen arbeiten. Sprich: Bei Wertänderung (F17) Funktion ausführen, die den vorherigen Wert mit den neuen Wert vergleicht. Wenn was hinzugefügt worden ist, ok. Wenn was weggenommen worden ist, rückgängig machen. Nicht super convenient, aber ein Beziehungsinput kann immer sowohl Hinzufügen als auch Entfernen.

Martin

Ah, OK. Die Möglichkeit des Hinzufügens wäre schon für den Workflow gut. Dann schaue ich mir mal Funktion bei Wertänderung an. Am besten noch mit Hinweis an den User, warum der Wert wiederhergestellt wurde.

Mitr ist gerade noch eine Alternative durch den Kopf gegangen: Das Feld mit dem Beziehungsattribut auf lesend setzen und dann noch für das Hinzufügen einen Button mit einem Frontendskript, das app.form_open aufruft. app.form_open scheint aber keine Möglichkeit zu haben die aktuelle Datensatz-ID zu übergeben, wie das im Builder durch die Option bei "Beziehung herstellen für neue Datensätze" möglich ist.

gabriel

app.form_open() kann die aktuelle Datensatz-ID übergeben, das ist der volle Aufruf:
app.form_open(form_id, record_id, new_tab, pop_up, max_height, max_width)

Zum Auslesen der ID des aktuellen Datensatzes, kannst du app.get_record_id(0) nutzen.

Martin

Ich glaube das passt nicht. Ich will ja aus dem Formular case, Relation case heraus einen neuen zugehörigen Datensatz in purchase zu erstellen:

Wenn ich das selbe per Button und form_open des purchase Formulars simulieren möchte, muss in form_open die record_id 0 sein für einen neuen Datensatz, und ich müsste zusätzlich irgendwie die record_id des case an das purchase Formular übergeben und dort als Wert für "0 purchase.case" setzen.

lsw-fabian

Martin Dafür könntest du doch den Value store im Frontend nutzen, damit kannst du deine Daten ins nächste Formular mitnehmen.

Martin

Danke für den Hinweis, schaue ich mir an 👍️ . Ich habe auch schon hier im Forum was zu dem Thema gefunden.

Wäre dann auch eine schöne Möglichkeit zumindest beim Aufruf über Frontendfunktionen das aufgerufene Formular zu ändern. Wie z.B. ein Feld auf read-only setzen und ähnlich.

Wenn es in späteren Versionen auch eine Möglichkeit gibt die möglichen Operation an der Relation programmatisch zu manipulieren, wäre das auch ein eleganter Weg ein Formular zu haben und dann umzuschalten zwischen "new und edit möglich" und "nur edit möglich", je nachdem von welcher Stelle aus das Formular aufgerufen wird.

Ich meine im Formular purchase die Option:

Wenn ich das Formular purchase aus dem 1:n Feld im Formular case öffne, um die Details genau nur dieses purchase zu sehen und zu bearbeiten, wäre es schön den Button "new" nicht zu haben. Es soll auf diesem Weg nur der Datensatz bearbeitet werden und kein neuer Datensatz erstellt werden. Ich habe jetzt das Formular dupliziert in ein edit-only Formular für den Zweck. Heißt dann natürlich auch, dass ich Änderungen an zwei Formularen durchführen muss. Luxusproblem, nice-to-have 🙂

gabriel

Ich hatte vor in R3.8 ein Feature reinzuboxen, was uns diese Möglichkeit gegeben hätte. Sprich: Man hätte im Frontend definierte Variablen setzen und damit auch den Formularzustand manipulieren können.

Leider kam es wie es musste und der Rotstift kam. Naja, umso mehr freue ich mich dann auf R3.9 🙂

Martin

Da freue ich mich dann auch drauf 🙂