---
title: ACS-MRS-HPE-RSKD-Collabo!
tags: RSKD, to-do, webapp
description: Shared document by ACS, MRS (a.k.a MSA), and HPE serving as a to-do list and (back)log concerning further development and troubleshooting of the RSKD server, database, and webapp
---

<font size="7">ACS-MRS-HPE-RSKD-Collabo! <br/>(A.C. feat. BigBadDataBase vs. Markuschi feat. Hanzo-Pětš)</font>

[TOC]

# To do

## <font color="darkorange">Sehr hohe Priorität</font>

## Hohe Priorität

#### 2024-10-17-H-2

- [ ] **GESEHEN**
- [x] **ERLEDIGT**
**WAS TUN:** beheben
**WO:** Datensatzeditor
**WARUM:** Beim Löschen von Datensätzen kommt es immer wieder zu RuntimeExceptions, u.a. zu dieser:
> Last cause: Cannot read field "id" because "this.record" is null

:::spoiler Stacktrace

Root cause:

java.lang.NullPointerException: Cannot read field "id" because "this.record" is null
at de.skipac.rsk.webapp.panels.recordeditor.RecordEditorModel.recordDeleted(RecordEditorModel.java:479)
at de.skipac.rsk.base.data.Data.fireRecordDeleted(Data.java:67)
at de.skipac.rsk.base.data.base.Table.deleteRecord(Table.java:1037)
at de.skipac.rsk.base.data.base.Record.delete(Record.java:327)
at de.skipac.rsk.webapp.panels.recordeditor.ctrl.ControlPanel\$ButtonDel.action(ControlPanel.java:296)
at de.skipac.rsk.webapp.layout.PageDialog$OptionDialog2\$Button.onClick(PageDialog.java:167)
at org.apache.wicket.ajax.markup.html.AjaxLink$1.onEvent(AjaxLink.java:85)
&hellip;

#### 2024-10-09-H-1

- [ ] **GESEHEN**
- [ ] **ERLEDIGT**
**WAS TUN:** Dubletten entfernen/konsolidieren
**WO:** Norm(!)-Dateninhalte von `rsk:place`
**WARUM:** Bei der Erfassung der Gemarkungen im `MTN`-Schema fällt auf, dass es bei den Orten im `RSK`-Schema teilweise Dubletten gibt. Das ist für _Normdaten_ fatal.
**KOMMENTAR (HPE):**
_Beispiel 1:_ Briesen/Brjazyna ist sowohl mit der ID 1641 (aus der Datenübernahme von Marcin?) als auch mit der ID 1280 (aus den pomniki?) angelegt. Außerdem gibt es noch die "Gemeinde Briesen", die sauber als "übergeordnete Körperschaft" des Ortes Briesen/Brjazyna erfasst sein müsste.
_Beispiel 2:_ Die _Gemeinde_ Crinitz taucht mit den IDs 2720 und 1408 doppelt auf. Der _Wohnplatz_ Crinitz mit der ID 2028 hat die Kategorie "Ort (Kerndorf)", aber keiner der beiden Gemeinde-Einträge ist übergeordnet.
_Allgemein_ scheinen öfter `@name:"Amtsfreie Stadt Xyz";@category:3`(Gemeinde) und `@name:"Xyz";@category:10`(Amtsfreie Stadt) nebeneinander zu existieren. Das muss aufgeräumt werden, sonst gibt's nachher großen Kuddelmuddel bei der Erfassung.
Vgl. auch [2024-10-10-N-1](#2024-10-10-N-1)

## Mittlere Priorität

#### 2024-12-13-M-1

- [ ] **GESEHEN**
- [x] **ERLEDIGT**
**WAS TUN:** Erweitern
**WO:** AttributeAuth
**WARUM:** Für die biographische Forschung sind zwei weitere Normdatenprovider interessant: die sächsische Biographie am ISGV und die Deutsche Biographie Online.
Die DeuBio hat eine Suchfunktion, `https://www.deutsche-biographie.de/search?...`, u.a. mit `freitext`, `name`, `gdr=m|f` (Geschlecht), `beruf`, `geburtsjahr`, `todesjahr`, `ort`, `gnd` (GND-ID). Die gibt HTML zurück.
Die SäBi hat auch eine Suchfunktion, doch die ist mit Javascript realisiert, also nicht direkt mit `GET`/`POST`. Aber dazu können vllt. die Leute vom ISGV was sagen. Wenn man die ID (_SNR_) recherchiert hat, kann man unter `https://saebi.isgv.de/person/snr/nnnnn` direkt verlinken.

#### 2024-10-30-M-1

- [ ] **GESEHEN**
- [x] **ERLEDIGT**
**WAS TUN:** Beheben
**WO:** API
**WARUM:** API-Zugriff auf Entitätstypen in anderen Schemata, z.B. `MTN`. Wenn HPE den URL `https://mtn.rskd.org/api/types` aufruft, bekommt er nur die Entitätstypen des RSK-Schemas angezeigt. Damit konsistent ist es, dass er beim Aufruf von `https://mtn.rskd.org/api/entities/name_record` ein HTTP-500 mit dem Fehler `Illegal or unsupported entity type name "name_record"!` bekommt. Es scheinen also unter allen Subdomains nur die Entitätstypen des RSK geliefert zu werden.

#### 2024-09-20-M-1

- [ ] **GESEHEN**
- [ ] **ERLEDIGT**
**WAS TUN:** Beheben
**WO:** Data Model, Formular-Layout, `grid()`
**WARUM:** Wenn in einer `grid()`-Anweisung innerhalb eines `html:`-Blocks ein HTML-Tag (z.B.: `<strong>`) fehlerhafterweise nicht geschlossen wird (hier fehlte das `>` im schließenden `</strong>`), wird das nicht bemerkt, sondern der Tag bleibt für den Rest des Formular-Layouts offen und führt u.a. zu merkwürdigen Positionierungen der Eingabefelder im Formular. Der fehlende schließende Tag wird offenbar stillschweigend (von wicket?, vom Browser?) ergänzt.
**KOMMENTAR (HPE):** :tada: Möglicherweise ist es auch ein erwünschtes Feature, dass HTML-Tags über die gesamte Formular-Darstellung hinweg offen bleiben können, weil man dadurch viel flexiblere Formularlayouts erzeugen kann. _Dann_ sollte der Parser trotzdem auf den auch am Ende nicht geschlossenen Tag hinweisen:exclamation:.

#### 2024-09-19-M-1
- [ ] **GESEHEN**
- [ ] **ERLEDIGT**
**WAS TUN:** Beheben
**WO:** Tabs
**WARUM:** Nachdem sich Tabs jetzt ihren Aufklappzustand merken, aktualisieren sie nicht mehr ihren Inhalt, wenn sie wieder angewählt werden – auch F5 ändert daran nichts. Beispiel: Entitätsliste öffnen (Tab 1 öffnet sich), eine Entität anwählen (Tab 2 öffnet sich), diese Entität löschen (Inhalt von Tab 2 ändert sich und zeigt jetzt die nächste Entität an). Somit müsste sich jetzt auch die Liste der Entitäten ändern. Klick auf Tab 1 zeigt Entitätenliste, die aber die gelöschte Entität noch enthält. F5 bringt nix.

#### 2024-06-28-M-1
- [x] **GESEHEN**
- [ ] **ERLEDIGT**
**WAS TUN:** Erweitern
**WO:** Data Model, Editor
**WARUM:** Wenn die Daten als _Linked Data_ bereitgestellt werden, müssen die Entitätstypen, Attribute und Attributwerte als RDF ausgewertet werden können.
**KOMMENTAR (HPE):** \
Das bedeutet:
1. jedem _Attribut_ muss ein RDF-Prädikat aus einem bekannten Vokabular (genauer: einer bekannten Ontologie) zugeordnet sein
2. wenn der Attributwert _kein Literal_ ist (betrifft _AttrubteAuth_ und _AttributeLink_), muss dem Ziel eine RDF-Klasse (=Datentyp) aus einer bekannten Ontologie zugeordnet sein
* Jedes Ziel eines _AttributeLink_ sollte bereits eine RDF-Klasse besitzen (s. „Entitätstypen“ unten)
* Gültige RDF-Klassen für _AttributeAuth_-Ziele hängen auch vom RDF-Prädikat ab; die meisten fordern genau eine bestimmte Klasse (`owl:sameAs` fordert z.B. dieselbe Klasse wie die seines RDF-Subjekts oder eine Unterklasse davon)
4. wenn der Attributwert ein _Literal_ ist, sollte der äquivalente (XML-)Datentyp als `"…"^^xsd:<datentyp>` angegeben werden (die Werte selbst werden immer als Strings geliefert) -- lt. Doku ist das ohnenhin der Standard in Apache Jena
5. bei einem _AttributeTuple_ mit mehreren Komponenten muss in der RDF-Ausgabe ein anonymer Knoten entstehen, für den dann alle genannten Punkte gelten.
* Die RDF-Klasse für den anonymen Knoten kann _optional_ angegeben werden. \
→ (Turtle)`…[rdf:type <ont>:<Klasse>; <ont>:<präd> <ont>:<obj>; … .]…`
5. jedem _Entitätstyp_ muss eine RDF-Klasse zugewiesen werden
- **ERGÄNZUNG (HPE):** HPE und ACS haben vereinbart: Die RDF-Vokabulare/Ontologien und Prädikate/Klassen werden als Kombination von zwei Auswahllisten angegeben: erste Liste = Ontologie, zweite Liste (erst aktiv, wenn Ontologie ausgewählt) = Prädikat bzw. Klasse aus der Ontologie. In der RDF-Ausgabe werden entweder die Präfixe/Namensräume zu URIs aufgelöst oder sie werden mittels `@prefix`-Anweisung definiert (das können auch mehr als die jeweils verwendeten sein; ist Apache-Jena-Standard). Die erste Liste enthält zunächst die in der RSK-Umgebung standardmäßig geladenen Ontologien; die zweite Liste deren jeweilige Klassen oder Prädikate, je nach Kontext.

#### 2024-06-21-M-1
- [x] **GESEHEN**
- [x] **ERLEDIGT**
**WAS TUN:** Hinzufügen
**WO:** grid()-Layout (Metaattribut `type.form`)
**WARUM:** MRS hätte gern die Option, ein Grid dazu zu zwingen, gleichmäßig breite Spalten zu erzeugen, z. B. `grid((columns:equal|auto))`. Das nötige CSS für das Grid-Element lautet `grid-auto-columns:minmax(0,1fr)`.
HPE hätte das auch gern.
**KOMMENTAR (MRS):** Kommt wahrscheinlich als Möglichkeit, dass HTML-Attribut `style` zu bestimmen, dort kann dann beliebiges CSS rein.

#### 2024-00-00-M-13
- [x] **GESEHEN**
- [x] **ERLEDIGT**
**WAS TUN:** Beheben?
**WO:** Datensatzeditor & Data Model > Entity Type Editor > layoutForm
**WARUM:** `AttributeText` und `AttributeMult`, wenn auf `multi` (mehrzeilige `textarea`-Elemente) gesetzt, bleiben auch dann nur optisch zweizeilig und wachsen nicht in ihrer `height` nicht mit, wenn für sie im Grid deutlich mehr Platz vorgesehen wird, also etwa bei `grid([1,1,1,50]@text_attr)`. Könnten sie (und auch ihre direkten Eltern-divs) vielleicht mit einer CSS-Regel `height: 100%;` voreingestellt sein?
**KOMMENTAR (ACS):** Wenn mehrere Layout-Komponenten den Platz beanspruchen, entsteht ggf. eine Verteilungskonflikt, oder? Wie wird der geloest?
**KOMMENTAR (MRS):** Ich spiele mal ein bisschen mit dem CSS rum und gebe dann Handlungsempfehlungen ab.
**KOMMENTAR (HPE):** Das scheint nicht vom CSS-Element `height` abzuhängen, sondern vom Attribut `rows` des `textarea`-Elements (Standardwert ist 2).

#### 2024-00-00-M-12
- [x] **GESEHEN**
- [x] **ERLEDIGT**
**WAS TUN:** Beheben
**WO:** Datensatzeditor
**WARUM:** Bei `AttributeLink` klappt das schnellere Hinzufügen (also ohne Plusknopf) schon. Wenn aber das `AttributeLink` ein Subattribut eines Tupels ist, muss man noch auf das nervige Plus klicken.
**KOMMENTAR (ACS):** Ja, der Tupeleditor ist noch auf der ToDo-Liste. Bevor ich den anfasse, koennten wir ja nochmal ueber die Attributverschachtelung Verschachtelung und das Layout des Tupeleditors philosophieren...

## Niedrige Priorität

#### 2024-12-18-N-2

- [ ] **GESEHEN**
- [ ] **ERLEDIGT**
**WAS TUN:** Erweitern
**WO:** Datensatzeditor, _AttributeLink_
**WARUM:** Die Repräsentationen von _Link_-Attributen werden abgeschnitten, wenn das Eingabefeld nicht breit genug ist. Das ist besonders auffällig, wenn der Link-Typ mit angezeigt wird, weil der auch noch Platz belegt.
In vielen Fällen werden in derselben Zeile andere Inhalte bereits umgebrochen, so dass genügend Zeilenhöhe vorhanden wäre. Es wäre schön, wenn man im Editor-Layout festlegen könnte, dass Repräsentationen umgebrochen werden (dürfen) oder das Layout selbst merkt, dass Platz fürs Umbrechen da ist, falls Wicket bzw. HTML das erlaubt.
**KOMMENTAR (HPE):** _\@MRS:_ Vielleicht geht das ja auch mit einem intelligent gewählten HTML-String in der Layout-Definition - hast Du eine Idee?

#### 2024-12-18-N-1

- [ ] **GESEHEN**
- [ ] **ERLEDIGT**
**WAS TUN:** Beheben
**WO:** Datensatzeditor, mehrzeilige Attribute (_Text_+_Mult_)
**WARUM:** Bei als mehrzeilig gekennzeichneten Textattributen wird das Eingabefeld auch bei leeren oder einzeiligem Inhalt mit doppelter Höhe dargestellt. Das belegt z.B. bei Tupelattibuten unnötig Platz, insbesondere wenn es ein Kommentarattribut ist, das nur selten benötigt wird (dann aber eben _möglicherweise_ mehrzeilig).

#### 2024-10-10-N-1

- [ ] **GESEHEN**
- [ ] **ERLEDIGT**
**WAS TUN:** Erweitern
**WO:** Datenmodell `rsk:place`
**WARUM:** Bei den Grunddaten der Orte fehlt eine Information darüber, ob der Ort noch existiert oder abgebaggert bzw. aus anderen Gründen aufgegeben wurde. Im Tagebaugebiet der Lausitz ist das sicher eine Grundinformation, die im Kerndatensatz mitgeführt werden sollte.
**KOMMENTAR (HPE):** Man könnte dazu ein kontrolliertes Vokabular mit den Zustandswerten `bewohnt`, `abgebaggert` und `aufgegeben (sonstiger Grund)` heranziehen. Auch bewohnte Orte sollten getagged werden, damit klar ist, dass diese Information bekannt ist. Die Frage ist, wie mit den übergeordneten Orten für abgebaggerte umgegangen werden soll.

#### 2024-10-04-N-1
- [ ] **GESEHEN**
- [ ] **ERLEDIGT**
**WAS TUN:** Erweitern
**WO:** Datensatzeditor
**WARUM:** Im MTN-Schema müssen oft viele ähnliche Datensätze (z.B. gleiche Quelle, gleicher Ort) nacheinander erfasst werden; deshalb wäre es gut, wenn man bei der Datenmodellierung (z.B. als Feldparameter im Formularlayout - so etwas wie`[…]@field(inputvalue: last)` vs. Standard `[…]@field(inputvalue: null)`) angeben könnte, dass für ausgewählte Eingabefelder die zuletzt eingegebenen Werte in eine neue Eingabe übernommen werden.
Wenn der Erfasser dann wechseln will, muss er einmal die gesamte Eingabe überschreiben, was nur einen minimalen Mehraufwand gegenüber der Neueingabe bedeutet, während Masseneingaben ziemlich beschleunigt werden könnten.
**KOMMENTAR (HPE):** Mein Lösungsansatz wäre, die Feldinhalte, die beim Anklicken von `Neu` da sind, zurückzuposten und die geposteten Werte als `value`s der entsprechenden `<input>`-Felder dem neuen Formular wieder mitzugeben (`Neu` geht ja ohnehin nur, wenn schon ein Datensatz bearbeitet wird).

#### 2024-09-24-N-1
- [ ] **GESEHEN**
- [x] **ERLEDIGT**
**WAS TUN:** Ändern
**WO:** Datensatzeditor für _AttributeCoord_`(viz: true)`
**WARUM:** Wenn ein Ortspunkt in einem _AttributeCoord_ (z.B. `rsk:place:coords`) gelöscht wird, wird der Fokus des Kartenausschnitts (bei `viz: true`) zurückgesetzt auf den Standardmittelpunkt bei Bautzen. Oft will man aber nur einen nicht ganz korrekt vorliegenden Ortspunkt ein wenig verschieben; daher wäre es sinnvoll, dass als Standardmittelpunkt der Karte immer der letzte Ortspunkt genommen wird, falls es schon einen gab. Damit kann ein Bearbeiter einen neuen, minimal veränderten Punkt auf der Karte manuell mit viel weniger Aufwand setzen und ohne die geographischen Koordinaten neu eingeben zu müssen.
Zusätzlich könnte auch `Löschen + Zurücksetzen`:x::house: (Verhalten wie bisher) als Option neben dem einfachen `Löschen`:wastebasket: vorgesehen werden (das hilft dann z.B. gegen versehentliche Vertauschung von Länge und Breite bei der Texteingabe, die einen in den Indischen Ozean vor die jemenitische Küste setzt :slightly_smiling_face:).
**KOMMENTAR (HPE):** Weil man den Marker auch auf der Karte verschieben kann, ist das vielleicht nicht ganz so wichtig. Wenn man numerische Koordinaten aus einer anderen Quelle hat, kann man die ja direkt eintragen.

#### 2024-09-04-N-1
- [ ] **GESEHEN**
- [ ] **ERLEDIGT**
**WAS TUN:** Hinzufügen
**WO:** Data Model, Tabellen-Layout für _AttributeLink_
**WARUM:** Das Tabellenlayout für _AttributeLink_ soll mehrere alternative Anzeigemöglichkeiten bieten: 1. Einen `<a…>`-Verweis auf das verlinkte Objekt; 2. Die Anzeige eines Attributs des verlinkten Objekts.
**KOMMENTAR (HPE):** ACS und HPE haben sich auf folgende Syntax für _AttributeLink_ in der Tabellenlayout-Spezifikation geeinigt: mit `@attribute_link` wird ein Verweis in der Tabelle angezeigt, mit `@attribute_link:@attribut` der Wert des entsprechenden Attributs der verlinkten Entität.
Das Tabellen-Layout für die Anzeige eines _AttributeLink_ (z.B. `@rsk_place`) auf einen `rsk:place` könnte also wie folgt aussehen `(… @rsk_place:@name, @rsk_place …)`. Damit würde zuerst der Name des Ortes und dann ein Verweis auf den verlinkten Ort angezeigt werden.
\[Ergänzung (HPE): mit `@attibute_link:*` (oder auch ohne `*`) könnte das definierte Tabellenlayout des verlinkten Entitätstyps aktiviert werden.]

#### 2024-09-04-N-2
- [ ] **GESEHEN**
- [ ] **ERLEDIGT**
**WAS TUN:** Hinzufügen
**WO:** Data Model, Tabellen-Layout für _AttributeTuple_
**WARUM:** Das Tabellenlayout für _AttributeTuple_-s (und die Syntax dazu) ist noch nicht festgelegt.
**KOMMENTAR (HPE):** Eine Möglichkeit ist eine `JSON`-Repräsentation des Tupels; eine weitere die explizite Auswahl eines bestimmten Tupels in diesem Attribut, z.B. durch `@tuples[0]` (das würde das Tabellen-Layout des _AttributeTuple_ für das erste Tupel verwenden). Wenn das entsprechende Tupel nicht vorhanden ist, wird stattdessen ein leerer String (oder ein Platzhalter wie \*\***NONE**\*\*) ausgegeben.
Ein Subattribut könnte dann durch `@tuples[0]:@subattribut` angesprochen werden. Ohne die Auswahl eines bestimmten Tupels (also `@tuples:@subattribut`) könnte eine Liste der jeweils vorhandenen Subattributwerte ausgegeben werden (ähnlich wie bei den _multilang_-Strings).
Ohne Angabe eines (oder mehrerer?) Subattribut-Namens ist das wahrscheinlich nicht sinnvoll.

#### 2024-08-13-N-1
- [x] **GESEHEN**
- [x] **ERLEDIGT**
**WAS TUN:** ~~Beantworten~~Hinzufügen
**WO:** Datensatzeditor, _AttributeLink_
**WARUM:** ~~Kann man im Eingabefeld eines _AttributeLink_ im Datensatzeditor auch nach etwas anderem als der ID suchen? Was muss ggf. im Datenmodell dazu eingestellt werden?~~
**KOMMENTAR:** Die Suchfunktion wird über den Schalter `FTS` der zu berücksichtigenden Attribute des Ziel-Entitätstyps aktiviert.
**ERWEITERUNG:** \[2024-09-20] ACS, MRS und HPE haben sich darauf geeinigt, dass zusätzlich auch immer die String-Repräsentation des Ziel-Entitätstyps durchsucht wird. Bisher schon wurde immer die interne ID mit durchsucht.

#### 2024-06-21-N-1
- [x] **GESEHEN**
- [x] **ERLEDIGT**
**WAS TUN:** Beheben
**WO:** Metaattribut `type.form` & Datensatzeditor
**WARUM:** Das Attributproperty `w` für das Gridlayout bestimmt nicht die Labelbreite, sondern den Labelinhalt (wofür eigentlich `l` vorgesehen ist). `l` scheint nichts zu bewirken.

#### 2024-06-18-N-2
- [x] **GESEHEN**
- [x] **ERLEDIGT**
**WAS TUN:** Beheben
**WO:** Datensatzeditor
**WARUM:**
Das Metaattribut `@doc.cat.comp.descr` (Attributbeschreibung) erlaubt im _Entity Attribute Editor_ die Eingabe von Zeilenumbrüchen. Hovert man im Datensatzeditor über dem Label eines Attributs, werden die Zeilenumbrüche aber nicht angezeigt. Nötig wäre wohl ein Umwandeln von bestimmten Zeichen (`\n` &rarr; `<br/>` oder so).

#### 2024-06-18-N-1
- [x] **GESEHEN**
- [x] **ERLEDIGT**
**WAS TUN:** Beheben
**WO:** Datensatzeditor
**WARUM:** Bei Tupel-Subattribut-Feldern des Typs `AttributeText` (sowohl bei einzeiligen `<input>` als auch bei mehrzeiligen `<textarea>`) fehlt die Bootstrap-Klassenangabe `class="form-control"`, wodurch die Felder nicht die volle zur Verfügung stehende Spaltenbreite ausnutzen.

#### 2024-06-14-N-2
- [x] **GESEHEN**
- [ ] **ERLEDIGT**
**WAS TUN:** Beheben
**WO:** CSS des Datensatzeditors
**WARUM:** Der Z-Koordinate der Autovervollständigen-Liste bei `AttributeLink` kollidiert mit weiter unten stehenden getupelten Link-Attributen, siehe `ll.text`, Attribut „Übersetzungsdistribution“
**KOMMENTAR (MRS):** Getupelte Link-Attribute will ACS ohnehin noch einmal überarbeiten (vgl. [2024-00-00-M-12](#2024-00-00-M-12)). Wenn danach die Z-Stapelung noch immer nicht richtig funktioniert, prüft MRS, woran es liegt und welche Werte für `z-index` zu empfehlen sind. Bis dahin ruht dieser Bug.

#### 2024-06-14-N-1
- [x] **GESEHEN**
- [ ] **ERLEDIGT**
**WAS TUN:** Hinzufügen
**WO:** Data Model > Entity Type Editor > layoutForm
**WARUM:** Für Attribute vom Typ `AttributeLink` besteht bisher die Möglichkeit, sie als vollumfängliche Dropdownliste (`all:true`) oder als Autovervollständigen-Feld (`all:false`) zu layouten. Diese nutzen gänzlich verschiedene HTML-Elemente mit verschiedenen daraus hervorgehenden Vor- und Nachteilen. So kennt etwa die Dropdownliste keinen Zeilenumbruch bei überlangen Auswahloptionen. Um Zeilenumbrüche zu ermöglichen und zugleich alle verfügbaren Optionen anzuzeigen, wäre eine dritte Option nützlich, die technisch der Autovervollständigung ähnelt, aber unabhängig von einer Sucheingabe alle Optionen anzeigt.
**KOMMENTAR (MRS):** Änderungen (Stand ca. 2024-06-17):
- `(all:true)` &rarr; `(type:"dropdownmenu")`
- `(all:false)` &rarr; `(type:"autocomplete")`
- neu: `(type:"listcomplete")` (noch nicht implementiert)

#### 2024-00-00-N-9
- [x] **GESEHEN**
- [ ] **ERLEDIGT**
**WAS TUN:** Hinzufügen
**WO:** Benutzerverwaltung
**WARUM:** Anlegen von neuen Nutzer*innen, falls das von ACS nicht unerwünscht ist.
**KOMMENTAR (ACS):** Doch, ist natuerlich erwuenscht. Ich lege Dir jeden sofort an, wenn Du das brauchst. Kann ich vor diesem Modul bitte noch ein paar wichtigere machen?
**KOMMENTAR (MRS):** Klaro.

## Eher egal

#### 2024-06-18-EE-1
- [x] **GESEHEN**
- [ ] **ERLEDIGT**
**WAS TUN:** Beantworten
**FRAGE:** Seit gewisser Zeit enthalten Felder des Typs `AttributeLink` mit der Eigenschaft `(all:true)` bzw. `(type:"dropdownmenu")` eine zusätzliche leere Option. Warum? Ist das Absicht?
**ANTWORT:**
**KOMMENTAR (HPE):** Kann es sein, dass man sonst keinen leeren Eintrag mehr anlegen könnte?

#### 2024-06-15-EE-2
- [x] **GESEHEN**
- [x] **IGNORE ERSTMAL**
- [ ] **ERLEDIGT**
**VGL.:** [2024-00-00-N-6](#2024-00-00-N-6), [2024-00-00-EE-2](#2024-00-00-EE-2)
**WAS TUN:** Beheben
**WO:** Datensatzeditor & Data Model
**WARUM:** Bestimmte DB-Änderungen erfordern ein Propagieren der geänderten Daten an andere Bereiche der Seite. Diese Propagation ist fehleranfällig und hat in der Vergangenheit Fehlermeldungen und kritische Abbrüche hervorgerufen. Für eine verbesserte UX wurden die Fehlermeldungen in Catch-Blöcken abgefangen. Nur ein Teil propagiert zuverlässig, bei anderen muss ein Reload manuell ausgeführt werden. Im finalen Produkt (in ferner Zukunft) sollte das behoben werden. Wär zumindest schön.

#### 2024-06-15-EE-1
- [x] **GESEHEN**
- [x] **ERLEDIGT**
**WAS TUN:** Beheben
**WO:** Vor allem im Data Model > Entity Attribute Editor, potenziell aber überall
**WARUM:** Die Begriffe `multi` oder `mult` stehen an mehreren Stellen für (mindestens) zwei verschiedene Konzepte: Mehrsprachige Textfelder (`AttributeMult`) und für mehrzeilige Eingabefelder (`<textarea>`). Vielleicht wäre es besser, diese eineindeutig zu benennen als z. B. `multilang` oder `multiling` bzw. `multiline`?

#### 2024-00-00-EE-4
- [x] **GESEHEN**
- [x] **IGNORE 4EVER**
- [ ] **ERLEDIGT**
**WAS TUN:** Beheben (und vereinheitlichen)
**WO:** überall
**WARUM:** An vielen Stellen ist noch von `RSK` die Rede. Sollte das nicht alles umgestellt werden auf `RSKD`? **OFFENE FRAGE! Schonnewidder in Lenkungsgruppe thematisieren! (auch wenn ACS das nicht will)**
**Anm. A.C.:** A.C. plaediert dafuer, dass Marek das bis zur naechsten Lenkungsgruppensitzung vergessen soll!

#### 2024-00-00-EE-3
- [x] **GESEHEN**
- [x] **IGNORE 4EVER**
- [ ] **ERLEDIGT**
**WAS TUN:** Beheben
**WO:** PuTTY
**WARUM:** MRS kommt nicht per PuTTY auf den Server (Problem mit Zertifikat?)
**KOMMENTAR (ACS):** Lass uns das beim naechsten JF beheben?!
**KOMMENTAR (MRS):** Nee, lieber nicht, wir haben so oder so immer mehr als genug durchzugehen. Dieses Anliegen hier ist wirklich _eher egal_.

<br/><br/><br/><br/><br/>

# :heavy_check_mark: Have done

#### 2024-00-00-M-11
**WAS TUN:** Beheben
**WO:** Sidebar im Hauptfenster
**WARUM:** Könnten die Schema-Überschriften als Ein- und Ausklapp-Buttons dienen, damit die Liste nicht so lang ist? Vielleicht könnten Sie im minimierten Zustand starten, damit man nicht so viel scrollen muss.
**KOMMENTAR (ACS):** Gute Idee, danke! Ich wuerd es gerne mit der Einfuehrung der Subschemata erledigen...

#### 2024-06-14-M-1
**WAS TUN:** Hinzufügen
**WO:** Datensatzeditor ~~Data Model?~~
**WARUM:** (Batch-/Bulk-)Import von Entitäten soll möglich werden.
**KOMMENTAR (MRS):** Vorerst darauf verständigt, dass das (primäre) Importformat ein JSON-Array sein soll, z. B. so:
:::spoiler Beispielcode ausklappen

    // unabhängig davon, ob nur eine Entität importiert werden soll
    // oder mehrere, soll das äußerste Datum ein Array sein
    [   
        // ein Objekt je einzufügender Entität
        {
            "oneAttrNameInDB": // oder AID (numerische Attribut-ID)
                "literal string", // String
            "anotherAttrNameInDB":
                4.5, // Zahl
            "andAnotherAttrNameInDB":
                { // mehrsprachiges Textattribut
                    "dsb": "dolnoserbski tekst",
                    "deu": "deutscher Text"
                },
            "yetAnotherAttrNameInDB":
                [125, 5], // komplexerer Attributwert
            "lastAttrNameInDB":
                [ // Tupel-Attribut
                    
                    { // erstes Tupel-Element als Objekt mit beliebiger Subattribut-Reihenfolge (weil explizit adressiert)
                        "nameOfSecondSubAttrInDB":   4,
                        "nameOfFirstSubAttrInDB":    "string",
                        "nameOfThirdSubAttrInDB":    [126, 7]
                    },
                    { // zweites Tupel-Element
                        "nameOfThirdSubAttrInDB":    [256, 19],
                        "nameOfSecondSubAttrInDB":   7,
                        "nameOfFirstSubAttrInDB":    "different string"
                    }
                    
                ]
        },
        // …
        {
            // …
        }
    ]

:::
Später vielleicht auch CSV-Import oder „unadressiertes“ (nicht mit Ziel-Attributnamen versehenes) JSON.

#### 2024-10-30-SH-1

**WAS TUN:** beheben
**WO:** API: `rsk.place`: Fehler bei Direktzugriff und Suche
**WARUM:** Über die RSK-API bekommt HPE beim Direktzugriff auf den Ort Nr. [1821](https://www.rskd.org/api/entity/place/1821) eine korrekte JSON-Antwort, beim Zugriff auf den von ihm neu angelegten Ort Nr. [2818](https://www.rskd.org/api/entity/place/2818) wird ein HTTP-500 mit `java.lang.reflect.InvocationTargetException` geworfen.
Das gleiche Verhalten zeigt eine Suche einmal mit einem [Namensteil von Nr. 1821](https://www.rskd.org/api/search/place?expr=Dubina) und einmal mit dem [Namen von 2818](https://www.rskd.org/api/search/place?expr=Teuplitz). Es scheint also ein Problem mit dem API-Zugriff auf bestimmte Entitäten zu geben.
_PS:_ In der JSON-Antwort taucht unter `"jsonurl"` noch `localhost` auf; das sollte sicher auch so nicht rauskommen.
**BEMERKUNG: (HPE+ACS)** Der Fehler lag daran, dass der API-Serverdienst seit Mai durchgelaufen war und nicht alle Datenänderungen mitbekommen hatte.

#### 2024-10-09-H-1

**WAS TUN:** Leere Suchfelder abweisen
**WO:** Datensatzeditor, `AttributeAuth`
**WARUM:** ~~Bei der Suche nach einem AttributeAuth mit leerem Suchfeld berichtet KK von einer `runtimeException`.~~ HPE und ACS konnten das nicht nachstellen: scheint einen anderen Grund gehabt zu haben.

#### 2024-06-28-M-2
**WAS TUN:** Erweitern
**WO:** Data Model Editor
**WARUM:** Bei _AttributeAuth_ muss ein leerer Eintrag für das inverse Prädikat möglich sein, weil viele RDF-Prädikate gar keine Inversen besitzen.
**VGL.:** [2024-06-28-M-1](#2024-06-28-M-1)

#### 2024-08-29-H-1
**WAS TUN:** Beheben
**WO:** Import
**WARUM:** `Unexpected runtime exception` beim Import in Entitätstyp `mtn:document`: `Illegal base64 character 3c` \
\[Anm(HPE): ASCII `3c` ist "&lt;", das im Eingabetext nirgendwo vorkommt.]
**KOMMENTAR (HPE):** Weitere Analysen:
- Der Fehler tritt auch auf, wenn ich versuche, eine exportierte JSON-Datei zurück zu importieren. Auch hier wird `3c` als _illegal character_ bemängelt.
- Es macht auch keinen Unterschied, ob die Eingabedatei in UTF-8 oder in ISO8859-2 kodiert ist.
- Auch ein Import in den Entitätstyp `mtn:name_record` erzeugt denselben Fehler.
::: spoiler Stack trace und Eingabedaten

~~~
java.lang.IllegalArgumentException: Illegal base64 character 3c
at java.base/java.util.Base64$Decoder.decode0(Base64.java:852)
at java.base/java.util.Base64$Decoder.decode(Base64.java:570)
at java.base/java.util.Base64$Decoder.decode(Base64.java:593)
at de.skipac.rsk.webapp.components.fileupload2.UploadResult.ofBase64(UploadResult.java:101)
at de.skipac.rsk.webapp.components.fileupload2.FileUploadWidget$1.respond(FileUploadWidget.java:655)
at org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:630)
[…]
~~~

Eingabedaten für den Entitätstyp `mtn:document`

    [
        {
            "@alias": "Zb130",
            "@bibliographic_citation": {
                "deu": "MUCKE, Ernst (= MUKA, Arnošt), 1918. Bausteine zur Heimatkunde des Luckauer Kreises: Im Auftrage des Kreisausschusses des Luckauer Kreises gesammelt, bearbeitet und herausgegeben von Studienrat Prof. Dr. E. Mucke. Luckau N.-L.: Kreisausschuß des Luckauer Kreises."
            },
            "@name": {
                "deu": "E.Mucke, 1918",
                "dsb": "A.Muka, 1918",
                "eng": "Ernst Mucke, 1918"
            }
        }
    ]

#### 2024-07-05-H-1
**WAS TUN:** Beheben
**WO:** Datensatzeditor
**WARUM:** Kritischer Abbruch, wenn MRS auf manche Entitätstypen anschauen will.
:::spoiler

Unexpected RuntimeException
Last cause: No write permission for Entity Attribute [3:301:30103] pom:category:sameas!

Stacktrace
Root cause:

java.lang.RuntimeException: No write permission for Entity Attribute [3:301:30103] pom:category:sameas!
at de.skipac.rsk.base.data.base.Tuple.set(Tuple.java:188)
at de.skipac.rsk.base.data.base.Table$RecordData.entity(Table.java:165)
at de.skipac.rsk.base.data.base.Table.lambda$query$12(Table.java:601)
at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
at java.base/java.util.TreeMap$ValueSpliterator.forEachRemaining(TreeMap.java:3250)
at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921)
at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:693)
at de.skipac.rsk.base.data.base.Table.query(Table.java:602)
at de.skipac.rsk.base.data.base.Graph.loadEntities2(Graph.java:146)
at de.skipac.rsk.base.data.base.Graph.loadEntity22(Graph.java:90)
at de.skipac.rsk.webapp.panels.recordeditor.RecordEditorModel.setRecordId(RecordEditorModel.java:337)
at de.skipac.rsk.webapp.panels.recordeditor.RecordEditorModel.applyFilter(RecordEditorModel.java:281)
at de.skipac.rsk.webapp.panels.recordeditor.RecordEditorModel.init(RecordEditorModel.java:110)
at de.skipac.rsk.webapp.panels.recordeditor.RecordEditorPanel.onInitialize(RecordEditorPanel.java:68)
at org.apache.wicket.Component.fireInitialize(Component.java:883)
at org.apache.wicket.MarkupContainer.internalInitialize(MarkupContainer.java:1045)
at org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:1022)
at org.apache.wicket.MarkupContainer.replace(MarkupContainer.java:861)
at de.skipac.rsk.webapp.layout.PageTabs.setActive(PageTabs.java:200)
at de.skipac.rsk.webapp.layout.PageTabs.open(PageTabs.java:181)
at de.skipac.rsk.webapp.layout.PageMenu$PanelTableDef$1.onClick(PageMenu.java:96)
at org.apache.wicket.ajax.markup.html.AjaxLink$1.onEvent(AjaxLink.java:85)
at org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:146)
at org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:630)
at org.apache.wicket.core.request.handler.ListenerRequestHandler.internalInvoke(ListenerRequestHandler.java:306)
at org.apache.wicket.core.request.handler.ListenerRequestHandler.invoke(ListenerRequestHandler.java:280)
at org.apache.wicket.core.request.handler.ListenerRequestHandler.invokeListener(ListenerRequestHandler.java:222)
at org.apache.wicket.core.request.handler.ListenerRequestHandler.respond(ListenerRequestHandler.java:208)
at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:910)
at org.apache.wicket.request.RequestHandlerExecutor.execute(RequestHandlerExecutor.java:63)
at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:294)
at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:255)
at org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:277)
at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:208)
at org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:137)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:799)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:550)
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624)
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1434)
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:501)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594)
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1349)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at org.eclipse.jetty.server.Server.handle(Server.java:516)
at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:400)
at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:645)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:392)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883)
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034)
at java.base/java.lang.Thread.run(Thread.java:1583)

display page view

:::

#### 2024-06-18-~~H~~M-1

**WAS TUN:** Hinzufügen
**WO:** AttributeAuth, Normdaten
**WARUM:** Normdaten für Sprachencodes ergänzen
**KOMMENTAR (HPE):** Namenvarianten und Lemmata können nach ihrer Sprache klassifiziert worden sein. Dabei ist die Auswahl absolut flexibel, d.h. es sollten nicht nur die Sprachen des RSKD unterstützt werden, sondern der gesamte Raum der ISO-639-2 (dreistellige Sprachencodes). Die Normdaten dazu liefert die US Library of Congress. Die Such-API unter https://id.loc.gov/vocabulary/languages/suggest?q=\<anfrage> unterstützt englische, deutsche und französische Sprachbezeichnungen sowie die Sprachcodes und liefert ein JSON-Array mit der Anfrage und den passenden Ergebnissen zurück.
**ERGÄNZUNG (HPE)**: AC und HPE haben sich darauf geeinigt, dass entsprechende Normdaten immer über das RSK referenziert werden sollen. D.h., dass an dieser Stelle ein _AttributeLink_ mit Verweis auf `rsk:language`verwendet wird. `rsk:language` kann dann weiter auf externe Normadten verweisen. So kann das beschriebene Normdatenelement als _AttributeAuth_ (`owl:sameAs`) später mit den Daten in `rsk:language` aufgenommen werden.
Beispiel-JSON ausklappen

    https://id.loc.gov/vocabulary/languages/suggest?q=*sb
    [
        "*sb",
        [
            "csb",
            "dsb",
            "hsb",
            "Usbekisch"
        ],
        [
            "1 result",
            "1 result",
            "1 result",
            "1 result"
        ],
        [
            "http://id.loc.gov/vocabulary/languages/csb",
            "http://id.loc.gov/vocabulary/languages/dsb",
            "http://id.loc.gov/vocabulary/languages/hsb",
            "http://id.loc.gov/vocabulary/languages/uzb"
        ]
    ]
    https://id.loc.gov/vocabulary/languages/suggest?q=niedersorbisch
    [
        "niedersorbisch",
        ["Niedersorbisch"],
        ["1 result"],
        ["http://id.loc.gov/vocabulary/languages/dsb"]
    ]

#### 2024-06-20-M-1
**WAS TUN:** Berechtigen
**WO:** Schema_1 (ID=10) umbenennen in „BIO“ und HPE Schreibrechte geben
**WARUM:** Basis-Schema für die Biographie-Datenbank herstellen
**KOMMENTAR (HPE):** HPE darf zwar mit einem schnellen Klick ein neues Schema anlegen, es dann aber nicht weiter bearbeiten &mdash; dabei hatte er sich so drauf gefreut&hellip;

#### 2024-00-00-N-10
**WAS TUN:** Beheben
**WO:** Data Model > Schema Editor
**WARUM:** Die automatisch ID-Vergabe für neuangelegte Entitätstypen zählt von 100 los und beachtet nicht die (menschliche?) Konvention, dass die dreistellige Entitätstyp-ID mit derselben Ziffer wie das Schema beginnen soll, falls noch kein Entitätstyp angelegt ist und somit nicht klar ist, von wo das Zählen fortgesetzt werden soll. Hypothetisches Beispiel: In neu angelegtem Schema 42 wird ein erster Entitätstyp mit automatisch vergebener Entitätstyp-ID angelegt. Dieser erhält, anders als vorgesehen, nicht die ID 4200 (oder 4201), sondern die erste freie ID ab 100.

#### 2024-06-17-SH-1
**WAS TUN:** Beheben
**WO:** Data Model > Entity Attribute Editor & Datensatzeditor
**WARUM:** MRS hat zum `AttributeTuple` `90010` (mit zwei Subattributen `90011` und `90012`) des Entitätstyps `900` ein weiteres Subattribut `90013` hinzugefügt, und das, obwohl bereits eine Entität dieses Typs angelegt und das Tupelattribut mit (zweimal zwei) Werten ausgefüllt war. Daraufhin kommt es wegen abweichender Subattributanzahl nun zu Problemen mit dem Entity Attribute Editor (Attribut `90013` kann nicht umtypisiert oder gelöscht werden) und ebenfalls mit dem Datensatzeditor (der konfligierende Datensatz kann nicht angezeigt, geschweige denn gelöscht werden).
:::spoiler Fehlermeldungen ausklappen
Fehlermeldung beim Löschen von Attribut `90013`:

java.lang.RuntimeException
Tuple size (2) does not match subattribute size (3)!
de.skipac.rsk.base.data.type.Tuple.(Tuple.java:46)
de.skipac.rsk.base.data.type.Tuples.ofJson(Tuples.java:403)
de.skipac.rsk.base.data.base.attributes.AttributeTuple.decodeJson(AttributeTuple.java:227)
de.skipac.rsk.base.data.base.attributes.AttributeTuple.decodeJson(AttributeTuple.java:49)
...
java.base/java.lang.Thread.run(Thread.java:1583)

Fehlermeldung beim Öffnen des Datensatzformulars für Entität `900` (`ll.text`):

Unexpected RuntimeException
Last cause: Tuple size (2) does not match subattribute size (3)!

Stacktrace
Root cause:

java.lang.RuntimeException: Tuple size (2) does not match subattribute size (3)!
     at de.skipac.rsk.base.data.type.Tuple.<init>(Tuple.java:46)
     at de.skipac.rsk.base.data.type.Tuples.ofJson(Tuples.java:403)
     at de.skipac.rsk.base.data.base.attributes.AttributeTuple.decodeJson(AttributeTuple.java:227)
     at de.skipac.rsk.base.data.base.attributes.AttributeTuple.decodeJson(AttributeTuple.java:49)
     at de.skipac.rsk.base.data.base.Attribute.fromJson(Attribute.java:501)
     at de.skipac.rsk.base.data.base.Record.<init>(Record.java:212)
     at de.skipac.rsk.base.data.base.Table$RecordData.entity(Table.java:143)
     at de.skipac.rsk.base.data.base.Table.lambda$query$12(Table.java:599)
     at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
     at java.base/java.util.TreeMap$ValueSpliterator.forEachRemaining(TreeMap.java:3250)
     at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
     at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
     at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921)
     at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
     at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:693)
     at de.skipac.rsk.base.data.base.Table.query(Table.java:600)
     at de.skipac.rsk.base.data.base.Graph.loadEntities2(Graph.java:146)
     at de.skipac.rsk.base.data.base.Graph.loadEntity22(Graph.java:90)
     at de.skipac.rsk.webapp.panels.recordeditor.RecordEditorModel.setRecordId(RecordEditorModel.java:337)
     at de.skipac.rsk.webapp.panels.recordeditor.RecordEditorModel.applyFilter(RecordEditorModel.java:281)
     at de.skipac.rsk.webapp.panels.recordeditor.RecordEditorModel.init(RecordEditorModel.java:110)
     at de.skipac.rsk.webapp.panels.recordeditor.RecordEditorPanel.onInitialize(RecordEditorPanel.java:67)
     at org.apache.wicket.Component.fireInitialize(Component.java:883)
     at org.apache.wicket.MarkupContainer.internalInitialize(MarkupContainer.java:1045)
     at org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:1022)
     at org.apache.wicket.MarkupContainer.replace(MarkupContainer.java:861)
     at de.skipac.rsk.webapp.layout.PageTabs.setActive(PageTabs.java:200)
     at de.skipac.rsk.webapp.layout.PageTabs.open(PageTabs.java:181)
     at de.skipac.rsk.webapp.layout.PageMenu$PanelTableDef$1.onClick(PageMenu.java:96)
     at org.apache.wicket.ajax.markup.html.AjaxLink$1.onEvent(AjaxLink.java:85)
     at org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:146)
     at org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:630)
     at org.apache.wicket.core.request.handler.ListenerRequestHandler.internalInvoke(ListenerRequestHandler.java:306)
     at org.apache.wicket.core.request.handler.ListenerRequestHandler.invoke(ListenerRequestHandler.java:280)
     at org.apache.wicket.core.request.handler.ListenerRequestHandler.invokeListener(ListenerRequestHandler.java:222)
     at org.apache.wicket.core.request.handler.ListenerRequestHandler.respond(ListenerRequestHandler.java:208)
     at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:910)
     at org.apache.wicket.request.RequestHandlerExecutor.execute(RequestHandlerExecutor.java:63)
     at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:294)
     at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:255)
     at org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:277)
     at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:208)
     at org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:137)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
     at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:799)
     at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:550)
     at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
     at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624)
     at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
     at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1434)
     at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
     at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:501)
     at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594)
     at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
     at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1349)
     at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
     at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
     at org.eclipse.jetty.server.Server.handle(Server.java:516)
     at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:400)
     at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:645)
     at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:392)
     at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
     at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
     at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
     at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
     at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338)
     at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315)
     at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173)
     at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
     at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:409)
     at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883)
     at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034)
     at java.base/java.lang.Thread.run(Thread.java:1583)

display page view

:::

#### 2024-00-00-SH-2
**VGL.:** [2024-00-00-M-10](#2024-00-00-M-10)
**WAS TUN:** Beheben
**WO:** Data Model > Entity Attribute Editor
**WARUM:** Ein Tupel-Problem hat sich wiederholt, diesmal in Entity Type 900. Wahrscheinlich liegt es daran, dass das Umbenennen der Subattribute nicht klappt. Oberflächlich gesehen funktioniert das Umbenennen, in der Entity-Attribute-Liste ist es unter neuem Namen zu finden. Intern aber (also im layoutForm-String) kann es unter diesem Namen nicht adressiert werden, wohl aber unter dem Default-Namen, den es ursprünglich getragen hat, also etwa `attribute_1`.

Sobald das Attribut (oberflächlich) umbenannt wurde, können auch keine weiteren Subattribute angelegt werden, was wohl auch daran liegt, dass das System ein neues Subattribut `attribute_1` anlegen möchte, das es aber intern noch/schon gibt.

Würde auch nachstehenden Bug erklären (aber nicht, warum das Subattribut gar nicht mehr zu sehen ist – es kann weiterhin unter `attribute_1` adressiert werden).

Solange das erste Subattribut aber im Front- wie im Backend noch `attribute_1` heißt, können weitere Subattribute angelegt werden (`attribute_2` etc.).

Betroffen sind konkret folgende Attribute:

|TID|AID|PID|sichtbarer Name|interner Name|
|-|-|-|-|-|
|900|90003|90002|content_entire_lang|attribute_1|
|900|90011|90010|content_part_lang|attribute_1|
|900|90012|90010|content_part|attribute_2|
|901|90104|90103|text|attribute_1|
|506|50605|50604|contact_link|attribute_1|

#### 2024-00-00-SH-1
**WAS TUN:** Beheben
**WO:** Data Model > Entity Type Editor
**WARUM:** MRS kann keine `de.skipac.rsk.base.data.base.attributes.AttributeForeign` anlegen
HPE auch nicht.

#### 2024-06-18-H-2
**VGL.:** [2024-00-00-H-1](#2024-00-00-H-1), [2024-00-00-N-4](#2024-00-00-N-4)
**WAS TUN:** Beheben?
**WO:** Datensatzeditor & Data Model > Entity Type Editor > layoutForm (grid)
**WARUM:** Grids von `AttributeTuple` werden nicht mehrzeilig dargestellt -- Beispiel im Entitätstyp *MTN.name_record*
::: spoiler
Ausgangssituation
: HPE legt ein `AttributeTuple` *name_variants* an mit zwei `AttibuteText` (*var_article* und *var_form*) und einem `AttributeAuth` (*var_language*). Dazu kommt als Subattribut ein weiteres `AttributeTuple` (*var_norm_names*) mit zwei `AttributeLink` (*var_norm_name* →`MTN.normalized_name` und *var_norm_cert* →`MTN.voc_certainty`)
Die `layoutForm` des Entitätstyps bleibt zunächst unverändert (alle Placements auf `[below]`), weil sie für den Effekt keine Rolle zu spielen scheint.
Die `layoutForm` für das Tupel *name_variants* enthält ein einzelnes `grid`-Element mit ausschließlich `[below]`-Placements. Die `layoutForm` für das Subttribut *var_norm_names* enthält ausschließlich `[right]`-Placements.

Erwartung
: In der Editor-Ansicht des Entitätstyps wird ein Eingabebereich für *name_variants* angezeigt, in dem die Attribute *var_article*, *var_form*, *var_language* **untereinander** angeordnet sind und **darunter** ein zweigeteilter Eingabebereich für *var_norm_names* mit *var_norm_name* und *var_norm_cert*.

Tatsächlicher Zustand
: Die `[below]`-Placements werden jedoch anscheinend ignoriert, so dass ein sehr breiter Eingabebereich angezeigt wird, in dem alle Subattribute nebeneinander angezeigt werden (dabei werden *var_norm_name* und *var_norm_cert* korrekt in einem gemeinsamem Unterbereich angezeigt).
Auch `[below]`-Placements in der `layoutForm` des untergeordneten `AttributeTuple` *var_norm_names* führen nicht dazu, dass die Eingabefelder untereinander angeordnet werden. Ebenso werden bei beiden `AttributeTuple`s absolute Zeilen- und Spaltenpositionierungen ignoriert.
:::
**KOMMENTAR (MRS):** Tatsächlich hatten ACS und MRS sich (wahrscheinlich in HPEs Abwesenheit) darauf verständigt, Tupel in Tupeln erst einmal nicht zu nutzen – zumal sich bei zu komplexer Verschachtelung ja ohnehin die Frage stellt, ob nicht ein solch tiefes Getupel lieber ein eigener Entitätstyp werden sollte.
Das `grid()` von Tupeln ist meines Wissens so oder so nicht voll funktionstüchtig, da es nicht als CSS-Grid, sondern als HTML-Table umgesetzt wird. `grid()` bestimmt bei Tupeln nur, welche Subattribute in welcher Reihenfolge auftauchen, sonst nix.
Wenn HPEs Datenmodell aber zwingend Tupeltupel erfordert, muss ACS halt ran.
**KOMMENTAR (HPE):** Das Datenmodell erfordert's nicht zwingend, allerdings würde es die Erfassung erleichtern, weil man in diesem Fall um das Anlegen von Entitäten für anonyme Knoten herumkäme. Die Alternative im obigen Fall ist, dass ein Entitätstyp *MTN.name_variant* genutzt wird und jede Variante noch einmal einen eigenen Eintrag bekommt. Das erfordert dann, dass diese zuerst eingetragen wird und muss im Fachworkflow berücksichtigt werden.

#### 2024-00-00-H-4
**WAS TUN:** Beantworten
**FRAGE:** Wo soll die Angabe `(all:true)`, um Dropdownfelder zu erhalten, hin, wenn das betreffene Attribut ein Subattribut eines Tupels ist?
**ANTWORT:** Na, in das Feld `formLayout`, aber nicht des Entitätstyps, sondern des Tupelattributs!

#### 2024-00-00-H-3
**WAS TUN:** Beheben
**WO:** Data Model > Entity Type Editor > formLayout
**WARUM:** `[1,next]` setzt die y-Koordinate nicht korrekt fort.

#### 2024-00-00-H-2
**WAS TUN:** Beheben
**WO:** Data Model > Entity Type Editor > formLayout
**WARUM:** Diakritische Zeichen im `[]text()`-String failen.

#### 2024-00-00-H-1
**VGL.:** [2024-00-00-N-4](#2024-00-00-N-4), [2024-06-18-H-2](#2024-06-18-H-2)
**WAS TUN:** Beantworten
**FRAGE:** Als Subattribut eines Tupel-Attributes hat MRS ein Tupel-Attribut angelegt. Ist diese Art von Verschachtelung erlaubt, vorgesehen und funktionabel?
**ANTWORT:** Geht nicht ordentlich. Im DB-Backend wahrscheinlich unproblematisch, im Frontend-Layout superschwierig. Deshalb lieber (erstmal oder für immer) nicht so nutzen.

#### 2024-00-00-M-10
**VGL.:** [2024-00-00-SH-2](#2024-00-00-SH-2)
**WAS TUN:** Beheben
**WO:** Data Model > Entity Type Editor & Entity Attribute Editor
**WARUM:** MRS hat ein Subattribut (`50605`) eines Tupelattributs (`50604`) angelegt, Typ zu `AttributeLink` geändert und den Namen zu `contact_link` geändert, dann kam folgende
Fehlermeldung

    java.lang.RuntimeException
    Cannot add element, because its name is already present in this set!

    de.skipac.commons.utils.collections.SetWithIndexIdName.add(SetWithIndexIdName.java:270)
    de.skipac.rsk.base.data.base.Attributable.addAttributeInteractive(Attributable.java:101)
    de.skipac.rsk.base.data.base.Attribute.replace(Attribute.java:465)
    de.skipac.rsk.webapp.util.catalog.CatCompProperty.lambda$wrapCatcher$f458fe69$1(CatCompProperty.java:143)
    ...
    java.base/java.lang.Thread.run(Thread.java:1583)

und im Anschluss war das gesamte Subattribut weg und seither lassen sich keine neuen Subattribute mehr anlegen (weder mit derselben ID, noch mit einer anderen, noch mit freigelassener ID), sondern es kommt diese Meldung:

    java.lang.RuntimeException
    Cannot add element, because its name is already present in this set!

    de.skipac.commons.utils.collections.SetWithIndexIdName.add(SetWithIndexIdName.java:270)
    de.skipac.rsk.base.data.base.Attributable.addAttributeInteractive(Attributable.java:101)
    de.skipac.rsk.webapp.panels.adminmodel.detailspanel.DetailsPanel$BlockCreate.create(DetailsPanel.java:273)
    de.skipac.rsk.webapp.widgets.WButton.action(WButton.java:82)
    ...
    java.base/java.lang.Thread.run(Thread.java:1583)

#### 2024-00-00-M-9
**WAS TUN:** Beheben
**WO:** Data Model > Entity Type Editor & Entity Attribute Editor
**WARUM:** Kann es sein, dass der formLayout-String eines Entitätstyps zurückgesetzt wird, wenn Änderungen an den Attributen vorgenommen werden (zum Beispiel Umbenennung oder Typänderung)? Oder aber neue Attribute werden einfach als `[below]@attribute_1` angehängt, der Attributname wird dann im weiteren Verlauf aber nicht mehr aktualisiert. Selbiges im `formLayout` von Tupelattributen.
**KOMMENTAR (ACS):** Zurueckgesetzt wird er nicht, aber ja ansonsten ist es genau so wie Du schreibst. Die ganzen Aenderungen mitzupropagieren ist irgendwie nicht ganz trivial. Aber mit der so resultierenden Fehlermeldung hast Du erstmal eine Erinnerung dort taetig zu werden und neue Attribute in das Form-Layout einzupflegen.
**KOMMENTAR (MRS):** Chronologie:
- Neuanlegen von Attributen zerschießt das `formLayout`
- Neuanlegen von Attributen fügt diese neuen Attribute mit ihrem Defaultnamen zum `formLayout` hinzu, aktualisiert sich dann aber nicht mehr und führt somit sehr schnell zu Fehlermeldungen
- Neuanlegen von Attributen fügt diese neuen Attribute mit ihrem Defaultnamen zum `formLayout` hinzu
Attributumbenennungen werden auch im `formLayout` vorgenommen
Attributlöschungen werden im `formLayout` nicht aktualisiert, um nicht das Layout zu zerschießen und per Fehlermeldung auf Handlungsbedarf hinzuweisen (Stand ca. 2024-06-14)

#### 2024-00-00-M-8
**WAS TUN:** Beheben
**WO:** Profile
**WARUM:** Benutzer*innen können ihr Passwort nicht selbstständig ändern.

#### 2024-00-00-M-7
**WAS TUN:** Hinzufügen
**WO:** Benutzerverwaltung
**WARUM:** Neue Berechtigungskategorien für globale Administration nötig. Bisher nur `Global User and catalog administration`, was MRS viiiel zu viele Rechte gibt.

#### 2024-00-00-M-6
**WAS TUN:** Beheben
**WO:** Data Model > Entity Type Editor > formLayout
**WARUM:** Hier eingetragene, aber nicht-existente Attribute erzeugen keine Fehlermeldung in der daraus erstellten Eingabemaske. OHA! ABER: Bereits bei der Eingabe wird eine Fehlermeldung ausgegeben! Schön!

#### 2024-00-00-M-5
**WAS TUN:** Ändern
**WO:** Datensatzeditor und Data Model > Entity Attribute Editor
**WARUM:** Verschiedene _foreign_ Entitätstypen auswählbar machen für ein und dasselbe `AttributeForeign`.
**KOMMENTAR:** Über neues `AttributeLink` gelöst.

#### 2024-00-00-M-4
**WAS TUN:** Beantworten
**FRAGE:** Ist es möglich oder soll es künftig möglich sein, als _foreign key_ nicht nur **eine** _table_ auszuwählen, sondern mehrere? Wenn z. B. die verschiedenen Belegtypen `Fragebogen` und `Zeitungsartikel` verschiedene Entitätstypen sind (weil sie ja über stark divergierende Attribute verfügen), aber in ein `AttributeForeign` eines dritten Entitätstyps potenziell beide eingetragen werden können sollen, was dann? (Lösungen: Bedingte Tupel-Subattribute? Vererbung? Übergeordnete Sammel-Entitätstypen?)
**ANTWORT:** Ja, das soll künftig möglich sein.

#### 2024-00-00-M-3
**WAS TUN:** Beheben
**WO:** Datensatzeditor
**WARUM:** Eine als _foreign key_ in das `AttributeForeign` einer anderen Entität eingebundene Entität hat eine nur sehr unzureichende Textrepräsentation und kann demnach nur über ihre numerische ID gesucht und gefunden werden. Entweder wäre für `de.skipac.rsk.base.data.base.DefaultRecord` ein defaultmäßiges Auslesen des `name` Attributs (falls es vorliegt) möglich oder aber eine Möglichkeit, im Entity Type Editor eine Textrepräsentation zu definieren.

#### 2024-00-00-M-2
**WAS TUN:** Beheben
**WO:** Data Model > Entity Attribute Editor
**WARUM:** Wenn MRS bei der Definition eines `AttributeForeign` im Feld `Layout Editor` den Wert von `[[1,1]]` zu `[[1,1,2]]` ändert, um zu erreichen, dass dann im Datensatzeditor alle _foreign entities_ als vollumfängliche Dropdownliste erscheinen, kommt es zu einem kritischen Fehler, der sich auch wiederholt, wenn man den Datensatzeditor der veränderten Entität ansteuert.

#### 2024-00-00-M-1
**WAS TUN:** Beheben
**WO:** Data Model > Schema Editor
**WARUM:** Es gab eine Exception, als MRS zu Schema 7 einen zweiten Entitätstyp hinzufügen wollte, aber keine ID dazu explizit angegeben hat. Der erste Entitätstyp 701 wurde mit explizit angegebener ID angelegt. Da aber jetzt unabhängig vom der Angabe einer ID kein neuer Entitätstyp angelegt werden kann, wird es wohl nichts damit zu tun haben. Betrifft übrigens nur Schema 7; wenn MRS ein 8. Schema anlegt, funktioniert das hinzufügen von Entitätstypen beanstandungslos.

#### 2024-00-00-N8
**WAS TUN:** Hinzufügen
**WO:** Data Model > Entity Attribute Editor
**WARUM:** Ein Attribut, das automatisch das Datum erfasst, an dem eine Entität angelegt wurde. Oder wird das schon irgendwo intern in der Datenbank erfasst?
**KOMMENTAR (ACS):** Mmh, hier gibt's das (noch) nicht. Bin da etwas voreingenommen... hatte das in R. damals umgesetzt, aber es hat eingen Aufwand bedeutet, wurde nie ernsthaft genutzt und mir im Zweifelsfalls als Spionage ausgelegt. Im TMD/POM hat man sich das als explizites Attribut der Entitaeten gewunscht, in denen es selber befuellt werden kann. Waere das eine Loesung, oder legst Du wirklich sehr grossen Wert auf ein automatisches "Logging"? Dann kann ich's hier auch einbauen.
**KOMMENTAR (HPE):** Sowas muss mit dem Personalrat abgestimmt werden.
**KOMMENTAR (MRS):** Dann lassen wir das. Wer wann eine Entität anlegt, werde ich einfach mittels zweier fakultativer Felder erfassen. Wer sich nicht nachverfolgen lassen will, lässt die dann halt einfach leer.

#### 2024-00-00-N-7
**WAS TUN:** Löschen
**WO:** Data Model
**WARUM:** MRS hat sich verklickt und aus Versehen ein 10. Schema angelegt. Kann gelöscht werden.
**KOMMENTAR (ACS):** Ja, Du hattest auch noch Schema 11 angelegt... habe sie mal beide geloescht. Und jetzt werde ich erstmal den Plus-Knopf an die Berechtigungen anschliessen. :)
**RICHTIGSTELLUNG (MRS):** Nein, ich habe kein Schema 11 angelegt. Das muss Hanzo-Pětš gewesen sein.
**GESTÄNDNIS (HPE):** per Zoom am 2024-06-18 :-) \<der [+]-Knopf ist wirklich **zu leicht** zu treffen!\>

#### 2024-00-00-N-6
**VGL.:** [2024-00-00-EE-2](#2024-00-00-EE-2), [2024-06-15-EE-2](#2024-06-15-EE-2)
**WAS TUN:** Beheben
**WO:** Datensatzeditor
**WARUM:** Das Löschen von Datensätzen (konkret: ICH > Fragebogen (Bräuche)) erzeugt eine RuntimeException. Das Neuanlegen auch. Beides funktioniert aber.
**KOMMENTAR (ACS):** Das sind wieder die komplexen Abhaengigkeiten im DOM, die Dinge auch entfernen und danach manchmal noch aendern moechten. Habe das wie im Modellierungsmodul in einen Catch-Block weggeklammert (wird also nur noch intern als Exception geloggt).

    Root cause:

    java.lang.IllegalArgumentException: Component [RecordIndicator [Component id = idValue]] cannot be updated because it is on another page.
         at org.apache.wicket.page.PartialPageUpdate.add(PartialPageUpdate.java:575)
         at org.apache.wicket.core.request.handler.AbstractPartialPageRequestHandler.add(AbstractPartialPageRequestHandler.java:99)
         at org.apache.wicket.core.request.handler.AbstractPartialPageRequestHandler.add(AbstractPartialPageRequestHandler.java:74)
         at de.skipac.rsk.webapp.panels.recordeditor.ctrl.ControlPanel$RecordIndicator.recordEditorModelDataChanged(ControlPanel.java:84)
         at de.skipac.rsk.webapp.panels.recordeditor.RecordEditorModel.fireDataChanged(RecordEditorModel.java:131)
         at de.skipac.rsk.webapp.panels.recordeditor.RecordEditorModel.recordDeleted(RecordEditorModel.java:460)
         at de.skipac.rsk.base.data.Data.fireRecordDeleted(Data.java:67)
         at de.skipac.rsk.base.data.base.Table.deleteRecord(Table.java:956)
         at de.skipac.rsk.base.data.base.Record.delete(Record.java:489)
         at de.skipac.rsk.webapp.panels.recordeditor.ctrl.ControlPanel$ButtonDel.action(ControlPanel.java:281)
         at de.skipac.rsk.webapp.layout.PageDialog$OptionDialog2$Button.onClick(PageDialog.java:156)
         ...
         at java.base/java.lang.Thread.run(Thread.java:1583)

#### 2024-00-00-N-5
**WAS TUN:** Beantworten
**FRAGE:** Wenn eine Entität per `AttributeLink` mit einer anderen Entität desselben Typs verknüpft werden soll, kann man dann ausschließen, dass sie mit sich selbst verknüpft wird?
**KOMMENTAR (ACS):** Derzeit nicht, das koennte man als Property von AttributeLink mal vorsehen. Andererseits befuerchte ich, dass das der Anfang einer ganzen Reihe von Einschraenkungswuenschen sein koennte, soll der Nutzer nicht selber mitdenken duerfen/muessen/sollen bzw. das erwartet werden koennen? :-D
**ANTWORT (MRS):** Wird es erstmal also nicht geben. Falls doch mal jemand so einen Quatsch macht, wird es spätestens bei Exporten oder Schnittstellenabfragen Fehler werfen und muss halt dann korrigiert werden.

#### 2024-00-00-N-4
**VGL.:** [2024-00-00-H-1](#2024-00-00-H-1), [2024-06-18-H-2](#2024-06-18-H-2)
**WO:** Datensatzeditor und Data Model > Entity Attribute Editor
**WARUM:** Tupel als Subattribute von Tupeln ermöglichen.
**KOMMENTAR (ACS):** Ich glaube das geht grundsaetzlich, moechte aber nicht wissen wie die geschachtelten Editoren dann auf die Benutzer wirken. ^^
Will man eigentlich nicht so ganz.

#### 2024-00-00-N-3
**WAS TUN:** Beheben
**WO:** Data Model > Entity Attribute Editor > formLayout
**WARUM:** [next] berücksichtigt nicht die Spanne der vorhergehenden Komponente.

#### 2024-00-00-N-2
**WAS TUN:** Beheben
**WO:** Data Model > Entity Attribute Editor
**WARUM:** Attribut 5060654 (`AttributeBoolean`) kann nicht gelöscht werden, weil zwei abhängige Attributwerte existieren.
**KOMMENTAR:** Lag daran, dass Boolean-Felder im Backend bisher drei Werte haben konnten: TRUE, FALSE und NULL. Optisch waren FALSE und NULL gleich, allerdings gilt FALSE als gesetzter Wert und NULL als nichtgesetzter Wert. Attribute mit (in Entitäten) gesetzten Werten können nicht gelöscht werden. FALSE könnte aber nicht manuell zu NULL umgewandelt werden. Gelöst, indem jetzt `AttributeBoolean` Felder nur noch zwei Werte zulassen: TRUE und NULL.

#### 2024-00-00-N-1
**WAS TUN:** Erklären
**WO:** Data Model > Entity Type Editor > repr
**WARUM:** MRS versteht nicht, wie die genaue Syntax für die Funktion cat() der Repräsentationsform lautet. `cat(" – ",@name,@descr)` hat nicht funktioniert, `cat('',name,descr)` auch nicht.

#### 2024-00-00-EE-2
**VGL.:** [2024-00-00-N-6](#2024-00-00-N-6), [2024-06-15-EE-2](#2024-06-15-EE-2)
**WAS TUN:** Beheben
**WO:** Data Model
**WARUM:** Seite aktualisiert sich nicht selbstständig, da sonst (beim Neuanlegen von Entity Types oder Entity Attributes?) Fehlermeldung kommt
**KOMMENTAR (MRS):** Vorerst gelöst für bestimmte Bereiche. In anderen muss noch manuell neu geladen werden, um Aktualisierungen anzuzeigen. Betrifft den gesamten Bereich `Data Model` und das Neuanlegen und Löschen von Entitäten.

#### 2024-00-00-EE-1
**WAS TUN:** Beheben
**WO:** Data Model > Entity Attribute Editor > multi
**WARUM:** Bei der Beschreibung des Properties `multi` des Entitätsattributs `AttributeText` steht `einzeligen` statt `einzeiligen`.

### EOF