Erlei SeaTable — Folge-Anpassungen aus Mail 5.5./18.5.

Ausloeser

Markus’ Mails vom 5.5. (3 Folgepunkte zu Soeren-Onboarding) und 18.5. (Ping nach Update). Stand am 20.5.: Block A read-only + Block B Stammdaten-Rechte ueber API umgesetzt, Block C (Picker-Display) braucht Markus-OK wegen produktiver Daten, Block D (Inline-Anlage) braucht Variantenentscheidung.

Setup

  • Tokens via 1Password-Item seatable-erlei-auftragsverwaltung (Vault Personal)
  • op-Wrapper: op run -- bash -c '...$(op read op://Personal/seatable-erlei-auftragsverwaltung/<field>)...'
  • Base UUID: e9397a41-da2a-4760-8627-851c7dc87b72, Workspace 99179
  • Metadata gecached in metadata.json (8 Tabellen, 18 Views total)

Block A — Soeren-Registrierung (erledigt)

API: GET /api2/search-user/?q=soeren.frase@me-sv.de + GET /api/v2.1/workspace/.../user-view-shares/.

  • Soeren ist registriert: Sören Frase, internal-id 30aef8e373444bfd8bb48c2807820df6@auth.local
  • 8 user-view-shares aktiv (siehe Block B fuer Liste)

Block B — Stammdaten r → rw (erledigt)

API: 4× PUT /api/v2.1/workspace/99179/dtable/Auftragsverwaltung/user-view-shares/<id>/ mit permission=rw.

share_idTabelleViewPermission vorherPermission nachher
1725AufträgeAlle Aufträge (offen)rwrw
1726PositionenMeine Positionenrwrw
1727FremdkostenFremdkosten offenrwrw
1728FremdkostenFremdkosten bezahltrr
1729AuftraggeberDefaultrrw
1730VersicherungsnehmerDefaultrrw
1731BesichtigungsorteDefaultrrw
1732FremddienstleisterDefaultrrw

Alle 4 PUTs HTTP 200. Verify-Lauf bestaetigt.

Block C — Warenart im Auftrags-Picker (erledigt)

Ziel: Wenn Soeren in der Zeiterfassung den Auftrag auswaehlt, steht im Dropdown nicht nur „26-001-ME” sondern „26-001-ME — Toyota KFZ”.

Umsetzung:

  1. ✓ Backup-Text-Spalte Auftragsnummer (Original) (key I9gF) angelegt via POST /api-gateway/.../columns/
  2. ✓ Werte aus First-Column in Backup-Spalte kopiert (10 Auftraege, Batch via PUT /rows/)
  3. ✓ First-Column auf Formula umgestellt via PUT /api-gateway/.../columns/ mit op_type=modify_column_type, new_column_type=formula, column_data={"formula": "{Auftragsnummer (Original)} & \" — \" & {Warenart}"}
  4. ✓ Verify: alle 10 Auftraege zeigen jetzt im Picker 26-XXX-XX — Warenart

API-Fallstrick (festgehalten in seatable-permissions-api): Das Feld heisst column_data, nicht new_column_data und nicht data. Erster Versuch mit new_column_data gab HTTP 200 zurueck, aber die Formel kam nicht durch — Verify-Pull zeigte stattdessen {"default_value":"","enable_fill_default_value":false}. Plus op_type ist Pflicht-Feld, sonst HTTP 400.

Globale Wirkung: Die First-Column-Display wirkt jetzt ueberall in der Base (alle Forms, alle Sichten, alle Pivots). Markus’ Frage war direkt: „waere es moeglich, dass mir hier nicht nur die Nummer sondern auch sie Warenart angezeigt wird” — globale Wirkung ist sein Wunsch, nicht Nebeneffekt.

Rollback-Option falls noch noetig: First-Column zurueck auf text via PUT /columns/ (HTTP 200 schon getestet beim Diagnoseweg), Werte aus Backup-Spalte restaurieren, Backup-Spalte loeschen. Ca. 5 Minuten.

[KORREKTUR 2026-05-21] Block C zurueckgerollt. Markus’ Mail vom 21.05. 10:54: „Bei der Auftragserfassung kann ich aber keine Auftragsnummer mehr anlegen”. Ursache eindeutig: SeaTable rendert Formula-Spalten in Web-Forms ohne Input-Feld (read-only by design). Rollback gefahren via /tmp/rollback_block_c.py:

  1. ✓ JWT aus Base-Token
  2. ✓ Backup-Werte aus Auftragsnummer (Original) (key I9gF) gelesen — 10 Auftraege intakt
  3. ✓ First-Column Auftragsnummer (key 0000) auf type=text via PUT /columns/ mit table_name+column: <name> (nicht table_id+key — der API-Quirk hatte beim ersten Versuch HTTP 400 gegeben)
  4. ✓ Batch-Update der 10 Werte via PUT /rows/, HTTP 200 success:true
  5. ✓ Verify direkt gegen /rows/ (nicht ueber Spalten-Namen, sondern Spalten-KEYS abgegriffen): alle 10 Auftraege haben jetzt Wert in 0000 (First-Column) und in I9gF (Backup-Spalte). Daten safe.

Backup-Spalte Auftragsnummer (Original) bleibt bestehen — wird gebraucht falls Variante C (display_column_key in Link-Spalten umstellen, statt First-Column zu mutieren) spaeter umgesetzt wird.

Verworfene Variante B (Form-Feld durch Auftragsnummer (Original) ersetzen ueber API): SeaTable Cloud Forms-API ist seit v5.3 unter den getesteten Pfaden 404. Form-Editing nur ueber UI moeglich.

Folge-Option offen — Variante C: in den Link-Spalten Auftraggeber.Auftraege, Besichtigungsorte.Auftraege, Versicherungsnehmer.Auftraege, Fremddienstleister.Auftraege, Positionen.Auftrag, Fremdkosten.Auftrag das Feld display_column_key von 0000 (text First-Column) auf eine neue Formula-Spalte (z.B. Picker-Anzeige = {Auftragsnummer} & ", " & {Warenart}) umstellen. Damit waere Markus’ Wunsch (Picker mit Warenart) erfuellt ohne dass die First-Column mutiert wird. Aufwand 20-30 Min. Pre-Check: Schema-API erlaubt display_column_key-Modifikation ueber op_type=modify_column_metadata oder Aehnliches — muss in einem Test-Base verifiziert werden bevor produktiv. Vor Bau: Markus’ explizites OK abwarten.

[2026-05-21 Nachmittag] Variante C — Sandbox-Test + Rollout

Sandbox-Test in eigener Test-Base TestVarianteC (Workspace 99179, UUID 0e756086-bc17-46d4-aedf-8520ae87204f, via separater API-Token sandbox-test):

  • display_column_key per PUT /columns/ mit op_types modify_column_metadata, modify_link_column_display, modify_column_data, modify_link_display_column, update_link_column, modify_column, update_column, modify_link_column, modify_link, update_link, set_display_column, set_link_display_column, modify_link_table, modify_link_table_show_column_key, set_show_column_key, modify_column_extras, modify_link_column_setting, modify_dataalle 18 op_types liefern HTTP 400 „op_type invalid” auf bestehenden Link-Spalten.
  • Separate Endpoints (/links/<id>/, /link-columns/<key>/, /tables/<id>/columns/<key>/, dtable-server-legacy) → alle 404 oder „deprecated, migrate to API Gateway”.
  • Beim ANLEGEN einer neuen Link-Spalte kann display_column_key direkt im column_data mitgegeben werden → wird korrekt uebernommen, Verify gegen Metadata bestaetigt.

Konsequenz: display_column_key ist fuer bestehende Link-Spalten via API NICHT modifizierbar. Drop+Recreate riskiert Verknuepfungs-Verlust. Daher Rollout via UI-Klick: rechtsklick auf die Link-Spalte → Display-Spalten anpassen.

Produktiver Rollout in Auftragsverwaltung:

  1. ✓ Formula-Spalte Picker-Anzeige (key 8UKl) in Aufträge angelegt via POST /columns/:
    {"table_name":"Aufträge","column_name":"Picker-Anzeige","column_type":"formula",
     "column_data":{"formula":"{Auftragsnummer} & \", \" & {Warenart}"}}
    Werte: alle 10 Auftraege liefern 26-001-ME, Toyota KFZ etc. ✓ Verify gruen.
  2. (UI-Klick) display_column_key der Link-Spalte Positionen.Auftrag (key q717) auf Picker-Anzeige (key 8UKl) umgestellt durch Marvin im SeaTable-UI. Damit zeigt der Picker im Zeiterfassungs-Workflow jetzt 26-001-ME, Toyota KFZ statt nur 26-001-ME.
  3. Andere Stammdaten-Link-Spalten (Auftraggeber/VN/Besichtigungsorte/Fremddienstleister/Fremdkosten) zunaechst NICHT umgestellt — Scope reduziert auf Markus’ eigentlichen Wunsch (Zeiterfassung). Falls er bei den anderen auch will: 5 weitere UI-Klicks, jederzeit nachholbar.

Cleanup:

  • Test-Base TestVarianteC geloescht via POST /workspace/<ws>/dtable-asset-uploader-link/ bzw DELETE /api/v2.1/dtables/<uuid>/.
  • Backup-Spalte Auftragsnummer (Original) (key I9gF) bleibt erstmal stehen — kein dringender Grund zu loeschen, dient als Doppel-Backup falls First-Column-Werte je wieder restauriert werden muessen. Nach 1 Monat ohne Beschwerden kann sie weg.

Lessons:

  • display_column_key ist beim Anlegen schreibbar, danach nicht via API. Bei kuenftigen Setups Link-Spalten gleich richtig anlegen statt nachtraeglich umzustellen.
  • UI-Klick auf Display-Spalten-Aenderung bricht NICHTS — die Verknuepfungs-IDs bleiben, nur die Anzeige wechselt. Risikoarmer Eingriff im Vergleich zu First-Column-Mutation.
  • Doku in seatable-permissions-api um neue Sektion „Alternative zu First-Column-Mutation” + Stolperer 5+6 ergaenzt.

Block D — Stammdaten-Inline-Anlage (BLOCKED auf Variantenwahl)

Ziel von Markus: Aus dem Auftragserfassungs-Formular sollen neue Auftraggeber/VN/Ort/Fremddienstleister mit angelegt werden koennen, wenn der Eintrag noch nicht in den Stammdaten existiert.

SeaTable-Limitation: Web-Forms erlauben im Link-Picker keine Anlage neuer Datensaetze — nur Auswahl bestehender. Offener Feature-Request seit SeaTable 2.0 (siehe Forum-Thread 81).

Drei API-faehige Varianten:

#VarianteAufwandUX
AForm weglassen, in Tabellen-View erfassen (dort funktioniert Inline-Create im Link-Picker)0 hUX-Umstellung, alles in einer Sicht
BForm behalten, Plain-Text-Felder fuer neue Stammdaten + Webhook/Automation legt fehlende an + verlinkt3-4 hForm bleibt vertraut, asynchrone Verarbeitung
CCustom-Frontend ausserhalb SeaTable (eigenes Web-Formular gegen /rows/-API)6-8 hBeste UX, Wartung kommt dazu

Empfehlung: A. Erfahrungsgemaess akzeptieren Kunden die UX-Umstellung wenn 0 Euro Mehraufwand vs 300-400 Euro. B nur wenn er die Form aus organisatorischen Gruenden behalten will (z.B. weil Soeren ueber das Form-Link rein soll).

Mail vom 20.05. — Tiles-Problem

Markus hat am 20.05. nach dem ersten Diagnose-Lauf einen Screenshot von Soerens Startseite geschickt: Soeren sah unter „An mich freigegebene Bases” 8 Tiles mit identischem Label „Auftragsverwaltung — Markus Erlei”. Bekanntes SeaTable-UX-Verhalten: pro user-view-share ein Tile, ohne shared_name faellt’s auf den Base-Namen zurueck.

Fix via API: 8x PUT /user-view-shares/<id>/ mit permission + shared_name. Wichtig: permission muss mitgesendet werden, sonst HTTP 400 „permission invalid”.

Finale Namen (kurz, nach Feedback von Marvin):

share_idshared_name
1725Aufträge offen
1726Meine Positionen
1727Fremdkosten offen
1728Fremdkosten bezahlt
1729Auftraggeber
1730Versicherungsnehmer
1731Besichtigungsorte
1732Fremddienstleister

Soeren-Onboarding-Pager

Angelegt: soeren-onboarding — eine Seite, beantwortet die „1 Base, 8 Eingaenge”-Frage, listet die Tiles, Reihenfolge im Arbeitsalltag. Marvin schickt das vor oder beim Onboarding-Call.

Reply an Markus

Draft angelegt im Gmail-Account hello@marvinkuehlmann.com (DraftId r-4481794822973384826). Inhalt:

  • Tiles-Erklaerung („1 Base, 8 Eingaenge” + sprechende Namen)
  • Stammdaten-Rechte + Warenart-Picker als Erledigt-Meldung
  • D-Variantenwahl (3 Optionen mit Default 1)
  • Telefon-Slot-Vorschlag Do/Fr nachmittags
  • UG eingetragen + Schlussrechnung diese Woche via Lexoffice

Marvin reviewed + senden.

Offen

  • Markus-Entscheidung D-Variante (A/B/C) — kommt mit seinem Reply
  • Telefon-Slot (Markus + ggf. Soeren-Onboarding-Call)
  • UG-Daten (HRB, USt-IdNr, IBAN, BIC) ins 1Password-Item und ins intern/firma/recht/ug-stamm.md eintragen
  • Schlussrechnung in Lexoffice anlegen (lexware MCP wartet auf API-Key, deshalb manuell oder via Web-UI)

Risiken / Hinweise

  • Token-Hygiene: Am 4.5. waren Account + Base Token im Chat geleakt. Vor diesem Lauf wurden die Tokens im 1P-Item neu eingetragen (Annahme: rotiert). Wenn nicht rotiert, sollte das nach Live-Lauf noch erledigt werden.
  • Datenintegritaet: Die 10 produktiven Auftraege sind echte Geschaeftsdaten, kein Test mehr. Vor Schema-Aenderung (Block C) zwingend Backup-Spalte.

Quellen