Editieren nach Speichern verbieten?

[Carsten Hof]

Hallo,

gibt es eine Möglichkeit, das nachträgliche Ändern eines Datensatzes zu verhindern?

Löscht man im Layoutmanager das Häkchen „aktiv“, kann in dieses Feld ja gar kein Wert eingetragen werden. Ich möchte dem Benutzer aber erlauben, einen Wert in einen neuen Datensatz einzutragen. Nach dem Speichern darf der Wert aber nicht mehr geändert werden.

Mit Statusmodell könnte man über eine Änderung der Aktion oder des Status selbst verschiedene Layouts verwenden. Da die betroffene Tabelle sehr groß ist, würde das Einführen eines Statusmodells aber die Performance deutlich verschlechtern. Ich möchte auch vermeiden, dass ein solcher Datensatz logisch gelöscht werden kann. Ist schon absehbar, wann die verschiedenen Features von Entitäten mit Statusmodell (Status, Aktion, logisch löschen, …) voneinander getrennt werden?

In Unterformularen würde auch das Statusmodell nicht weiterhelfen, da dort gleichzeitig neue und schon bestehende Datensätze angezeigt werden.

Gibt es noch eine andere Möglichkeit, das nachträgliche Ändern zu verhindern? Schön wäre z.B. ein Haken im Layoutmanager, der angibt, dass das betroffene Feld beim neu anlegen editiert werden darf, danach aber nicht mehr. Oder eine Unterscheidung bei der Verwendung der Layouts nicht nur zwischen „Suchmaske“ ja/nein, sondern Suche, Neu und Bearbeiten.

Gruß,

Wolfgang

[Ramin Goettlich]

Hallo,

wurde denn schon ausprobiert, ob eine Entität ohne Statusmodell langsamer wäre? Langsamer an welchen Stellen?

In Unterformularen könnte man ein Groovy-Skript bei der Property „Bearbeiten aktiv (dynamisch)“ hinterlegen, z.B.

if ((null!=context."#{NUCLET.Entitaet.Feld_das_bei_neuen_Datensätzen_leer_ist}")){
if(context.field == "#{NUCLET.Entitaet.Feld_das_bei_vorhandenen_Datensätzen_nicht_geändert_werden_darf}")
return false }
return true

und vermutlich (nicht ausprobiert) analog bei der Property „Aktiv (dynamisch)“ bei den Feldern im Hauptformular.

Grüsse,
nuclosian

[Autor]

Beiträge