Drei Anmerkungen:
Natürlich bekommst Du eine Sicherheit wegen der Bearbeitbarkeit nur via Autorenfelder - dies wurde ja schon erwähnt. Wenn Du derzeit nur eine Sperre im QueryModeChange eingebaut hast, ist dies ja zudem noch ganz simpel zu umgehen: Drücke Strg-B (deutscher Client, im englischen Ctrl-E) aus einer Ansicht heraus, und QueryModeChange wird überhaupt nicht getriggert.
Prinzipiell: Was das Ändern von Items im Backend angeht, wurde der passende Code ja schon gepostet. Und genauso, wie das Item "Status" geändert wird, können auch die beiden anderen Items auf neue Werte gesetzt werden.
Last but not least: Du setzt LS ein, um "das Bearbeiten zu verhindern" (QueryModeChange), sagst aber , dass Du da nicht fit bist. Du begibst Dich damit auf extrem dünnes Eis (siehe das vergessene Event PostOpen, ggf. auch PostRecalc).
Matthias "TMC" schrieb es schon: Das Verändern von Dokumenten kannst Du durch pures Reagieren auf FrontEnd-Aktionen nie und nimmer verhindern, und Notes stellt deshalb ja auch ganz andere Möglichkeiten zur Verfügung. genauso, wie wir es hier beispielhaft beschrieben haben, kann sich jeder halbwegs begabte User selber einen Agent schreiben und Items verändern, wie es ihm gerade beliebt.
Was Namensfelder angeht: Das kann man machen, muss man aber nicht, denn Namensfelder unterscheiden sich von normalen Textfeldern nur durch zwei wesentliche Eigenschaften:
Canonical names werden im FrontEnd abbreviated angezeigt (also aus "CN=Hein Bloed/O=Kutter/C=Meer" wird eben "Hein Bloed/Kutter/Meer".
Und - zumindest ab R6 - können Namensfelder via den Administrationsserver in den Administrationsprozess einbezogen werden (Löschungen von Usern, Umbenennungen, Rezertifizierungen). Letzteres kann sehr erwünscht sein, aber auch zutiefst kontraproduktiv (Beispiel: Alle Anträge gelöschter Mitarbeiter weisen im Namensfeld "Antragsteller" plötzlich nur noch Leerstrings auf).
Der Einsatz von Namensfeldern versus Textfeldern will also sehr wohl durchdacht sein.
Bernhard