EDIT

mail NK:

es gibt noch ein Desideratum, das wir im Projekt schon identifiziert hatten und das auch Murat schon mal angesprochen hat; weiß nicht ob schon irgendwo vermerkt:
Eine Funktion, mit der eine Matrixzelle manuell als "inapplicable" getaggt werden kann, damit sie von (noch) nicht ausgefüllten Zellen unterschieden werden kann (hilft beim Ausfüllen und ist relevant bei weiterer Verwendung der Matrix als e.g. ancestral character reconstruction zur Unterscheidung von missing characters).
Das impliziert, dass diese Funktion sich über hinterlegte Statelisten und als numerische State "hinwegsetzen" kann.

mail AM:

ein interessantes Thema. Kannst du das noch ein bisschen weiter ausführen? Es gibt ja bislang bereits bei den Characters die Möglichkeit „inapplicableif“ und „onlyapplicableif“ anzugeben. Das wurde von Xper² abgeschaut und findet bislang bedingt Anwendung. Vielleicht ist es aber genau das, um was es hier geht. Mein Verständnis wäre, dass man für jeden Character bzw. genauer für jeden Character-Knoten im Character-Baum mit „inapplicableif“ angeben kann, welche States Eltern-Characters nicht annehmen dürfen, damit der Character noch Sinn macht. Wenn ein solcher State doch ausgewählt wurde, sollte das dazu führen, dass die entsprechende Zelle in der Matrix auf „inapplicable“ bzw. uneditierbar gestellt wird, etc.
Stimmt da mit dem überein, was du und Murat brauchen?
Entsprechendes gilt dann natürlich auch für onlyapplicableif, nur dass das eine eine Positiv-Liste ist und das andere eine Negativ-Liste.

mail NK:

ja genau darum geht es, aber diese Optionen bei den Characters wurden ja nicht realisiert (stehen aktuell funktionslos im Character DetailsView) und irgendwie hatte sich bei mir festgesetzt, dass das zu kompliziert sei, aber das wäre natürlich der elegantere Weg.

mail AM:

Katja, was meinst du, wäre das schwierig zu implementieren? Also es geht darum, Felder auszugrauen, ähnlich wie bei den Feldern, die durch Default Descriptions abgedeckt sind.
Im konkreten Fall müsste geschaut werden, ob der Character-Node des Feldes ein inapplicable-if oder only-applicable-if besitzt. Wenn ja, müsste man für alle Eltern-Character auswerten, welcher Wert/State diesem Character in derselben Description zugewiesen ist (also in einer der Spalten, die in der Regel weiter links erscheint). Wenn es ein State ist, der in der inapplicable Liste steht, muss das Feld ausgegraut/nicht editierbar gemacht werden.
Typisches Beispiel: Eine Struktur hat den Character „present“. Falls hier absent ausgewählt ist, sollten die Unter-Characters natürlich nicht editierbar sein.
Könntest du dafür ein Ticket anlegen, wenn du denkst, dass das machbar ist?

Natürlich sollte sich der Zustand on-the-fly ändern, wenn der State des Eltern-Characters sich ändert durchs editieren. Zudem brauchen wir eine Warnung für den Fall, dass Felder inapplicable werden durch eine Änderung in Elternfeldern, wenn aber in den Kind-Feldern Daten enthalten sind. Die Frage ist auch, ob das Feld dann gelöscht werden soll oder ob es mit einem gut sichtbaren Hinweis auf fehlerhafte Daten erstmal bestehen bleiben soll. Ich tendiere zu löschen, aber evtl. erst beim Speichern um evtl. ein Undo möglich zu machen.
Zudem müsste man schauen, was ist, wenn der Eltern-Character mehrere Werte hat, also z.B. Blattfarbe rot und grün, und nur rot als inapplicableif gilt. Ich würde sagen, dass dann das inapplicable nicht gilt, bin aber unsicher. Ähnlich bei onlyapplicableif. Editierbar wenn mind. ein State in only-applicable-if enthalten ist oder wenn alle enthalten sind? Auch hier würde ich dafür plädieren, dass mind. ein State ausreicht. Was meinst du, Norbert?

mail NK:
Felder ausgrauen: ja und zugleich mit einem Wert wie "n.a." (= not applicable) füllen, damit bei einem Export diese Felder von solchen mit fehlenden Daten unterschieden sind.

Multiple states und inapplicable: Ich denke auch, Felder müssen editierbar bleiben, solange 1 der multiplen states in only-applicable-if enthalten ist.

Bei der Auswahl der Bedingungen im only-applicable-if / not applicable if, müsste durch + ein Hinzufügen von mehr als einer Bedingung ermöglicht werden.