LockedAccess & Read-Only + Editier-Ausnahmen

Diese Seite erklärt, warum Projekte in der SalesApp und WebApp gesperrt sein können, welche zwei Sperr-Arten es gibt und wie man einzelnen Rollen erlauben kann, bestimmte Felder trotzdem zu bearbeiten — über die Formular-Konfiguration.

1. Warum sind Projekte manchmal gesperrt?

Damit z.B. bereits beauftragte Projekte oder Projekte mit veralteter Preisliste nicht versehentlich verändert werden, sperren die Apps (iPad-SalesApp und WebApp) sie für die Bearbeitung. Es gibt dabei zwei unterschiedliche Sperr-Arten — sie sehen ähnlich aus, bedeuten aber Verschiedenes.

2. Die zwei Sperr-Arten

🔒 LockedAccess (Status-Sperre)

Das Projekt ist wegen seines Status gesperrt (z.B. „beauftragt" / „bestätigt").

In der App erscheint der Hinweis „LockedAccess".

Es ist eine Teilsperre: die meisten Felder sind gesperrt, das Projekt gilt aber grundsätzlich noch als aktiv/bearbeitbar.

👁 ReadAccess (Read-Only / Vollsperre)

Das Projekt ist komplett schreibgeschützt — weil die Person keine Bearbeitungsrechte hat ODER die Preisliste ungültig/veraltet ist.

In der App erscheint „ReadAccess" (Lesezugriff).

Es ist eine Vollsperre: kein Feld ist bearbeitbar.

Unterschied in einem Satz: LockedAccess ist eine status-bedingte Teilsperre (weich), ReadAccess eine vollständige Lese-Sperre (hart). Trifft beides zu, gilt immer ReadAccess (die Vollsperre hat Vorrang).

3. Was kann man in der Config einstellen?

Formulare werden über eine Konfiguration gesteuert, die pro Feld dessen Verhalten festlegt. Für jedes Feld lässt sich u.a. bestimmen:

der Grundzustand (type): optional, required (Pflichtfeld), readonly (nur lesen) oder hidden (ausgeblendet);

Ausnahmen bei Sperre: einzelne Felder dürfen — für bestimmte Berechtigungen — trotz Sperre bearbeitet werden.

Editier-Ausnahmen für gesperrte Projekte

Zwei Einstellungen erlauben einer berechtigten Gruppe, ein Feld trotz Sperre zu bearbeiten. Der Wert der Einstellung ist die benötigte Berechtigung:

editable-when-locked – das Feld ist bei LockedAccess (Status-Sperre) bearbeitbar.

editable-when-readonly – das Feld ist bei ReadAccess (Read-Only) bearbeitbar.

Beispiel: Status und Auftragsnummer sollen für den Innendienst editierbar bleiben, auch wenn das Projekt gesperrt ist:

{
  "name": "status",
  "type": "readonly",
  "editable-when-locked":   "app_edit_state_service",
  "editable-when-readonly": "app_edit_readonly_service"
}

Hier steht app_edit_state_service bzw. app_edit_readonly_service für die Berechtigung, die eine Benutzergruppe haben muss.

4. Was passiert dann in den Apps?

Ein Feld ohne Ausnahme bleibt im gesperrten Zustand nicht bearbeitbar.

Ein Feld mit editable-when-locked wird bei LockedAccess bearbeitbar — aber nur für Personen mit der angegebenen Berechtigung.

Ein Feld mit editable-when-readonly wird bei ReadAccess bearbeitbar — ebenfalls nur mit der Berechtigung.

Für alle anderen Personen bleibt das Projekt unverändert gesperrt.

Freigegebene Felder werden ganz normal gespeichert.

Wichtig: Die angegebene Berechtigung muss existieren und der jeweiligen Benutzergruppe zugewiesen sein. Ist das nicht der Fall, passiert nichts — die Einstellung bleibt wirkungslos.

5. Weitere Feld-Einstellungen (Kurzüberblick)

6. Beispiel aus der Praxis

Der interne Innendienst soll auch an gesperrten Projekten noch Status und Auftragsnummer pflegen können — etwa um Altbestellungen zu Altkonditionen nachzutragen. Dazu werden die beiden Felder mit editable-when-locked und editable-when-readonly versehen und die zugehörigen Berechtigungen den internen Gruppen zugewiesen (z. B. Administration und Innendienst). Ergebnis: Diese Gruppen können die zwei Felder in beiden Sperr-Arten bearbeiten; alle übrigen Felder und alle anderen Benutzer bleiben gesperrt.