Bei der Volltext-Suche in Grid-Komponenten kommt es zu Abstürzen, wenn technische
Spalten unbeabsichtigt Standard-Resource-Provider zugewiesen bekommen.

2025-10-30T10:18:26,547 ERROR [qtp756936249-65]: com.top_logic.basic.util.ResourcesModule - Missing resource '[layouts.demo.table.table_grid.tableGrid.row0]'. S(dDrkqth32wcqnFV2mZsSl2xoyvvOln+Cqa/fKF2b5aE=) 
java.lang.Exception: Stacktrace
	at com.top_logic.basic.util.ResourcesModule.newUnknownKey(ResourcesModule.java:568)

Das Problem tritt wie folgt auf:
- Tabellen unterstützen die Volltext-Suche über alle Spalten
- Für jede Spalte wird ein "Full Text Resource Provider" verwendet, um durchsuchbare Daten zu
erhalten
- !Technische/Hilfsspalten werden explizit mit null als Provider konfiguriert, um sie von der Suche
auszuschließen
- Während des Tabellen-Lebenszyklus wird diesen technischen Spalten trotzdem ein Standard-Provider
zugewiesen
- Bei der Volltext-Suche wird versucht, diesen Provider zu verwenden, was zu einer
Fehlermeldung wie "Resource Provider not found" führt

Das eigentliche Problem ist, dass der explizite null-Wert durch einen Standard-Provider
überschrieben wird.

Ursache

Die Ursache liegt im Kopiermechanismus der Tabellenspalten-Konfiguration:

1. Wenn eine Spalte explizit mit setFullTextProvider(null) konfiguriert wird, wird das Flag
fullTextProviderExplicitlySet auf true gesetzt
2. Während des Tabellen-Lebenszyklus werden Spalten kopiert/geklont
3. Bei diesem Kopiervorgang wird das fullTextProviderExplicitlySet-Flag nicht mitkopiert und auf
false zurückgesetzt
4. Später, wenn Tabellen-Konfigurationsprovider Standardwerte zuweisen, wird
setFullTextProviderAsDefault() aufgerufen
5. Da das Flag jetzt false ist, wird der Standard-Provider zugewiesen und überschreibt die
ursprüngliche null-Einstellung
6. Die technische Spalte hat nun einen Provider, obwohl sie für die Volltext-Suche ignoriert
werden sollte

Die Logik kann nicht mehr zwischen "es wurde kein Provider gesetzt" und "es wurde explizit null
gesetzt, um auszuschließen" unterscheiden.

Möglicher Lösungsweg

Der kleinste und sicherste Lösungsweg ist die Sicherstellung, dass das
fullTextProviderExplicitlySet-Flag während des Spalten-Kopiervorgangs korrekt erhalten bleibt:

1. Hinzufügen einer copyFullTextProviderExplicitlySet()-Methode in der ColumnDescription-Klasse,
die das Flag kopiert
2. Anpassung der copyFrom()-Methode, um die neue Methode während des Kopiervorgangs aufzurufen
3. Sicherstellung, dass das Flag bei allen Spalten-Klonoperationen korrekt mitkopiert wird

Dieser Ansatz:
- Behält die bestehende API-Semantik bei
- Ist minimal und invasiv
- Löst das Problem an der Wurzel (fehlendes Flag-Kopieren)
- Beeinflusst keine andere Funktionalität

Test

Prüfen ob in TL-Demo bei einer Volltext-Suche der Fehler auftaucht.