Mark JavaScript methods that exist in only one context

[christophdb]

Problem

A support ticket reported that base.insertColumn(), base.renameColumn(), base.modifyColumnType(), base.addColumnOptions() and base.deleteColumn() are undefined in a base's JavaScript script editor, although the reference documents them.

The report is correct, and so was the reading of the docs. The JavaScript reference merges two APIs that are not identical:

• Script in SeaTable — base is a browser-side SDK instance. Read-only access to columns.
• External client — base comes from npm install seatable-api. Full column management.

index.md claimed "The core methods (tables, views, columns, rows, links, SQL) are the same in both contexts. Features that are only available in one context are clearly marked" — but only 6 methods carried a marker, and none of the column write methods did. The examples on the columns page even open with import { ColumnTypes } from 'seatable-api';, which is impossible in the script editor.

This became visible with #NN (0d59065), which merged the previously separate scripting and client documentation trees. The docs were unified; the APIs were not.

Changes

• New marker :material-package-variant-closed: External client only, deliberately a different icon from the existing scripting tag so the two cases are distinguishable
• 16 methods marked external-only: all column write methods, listRows, insertRow, batchAppendRows, batchUpdateRows, batchDeleteRows, batchUpdateLinks, updateLink, getMetadata
• The reverse case fixed: getColumns and getRows are scripting-only and do not exist in seatable-api — external users ran into the mirror image of the same bug
• updateLinks added as its own scripting entry (same method, different name in the two contexts)
• Legend for both markers on the index page — there was no explanation of the marker anywhere in the repo, it was a bare tooltip
• Corrected the index claim about context parity, added a "Column management" row to the comparison table
• Context notes on constants.md (no import in the script editor) and files.md (Node.js only)
• Warning box at the top of columns.md pointing scripting users to Python or the REST API

tables.md and views.md needed no changes — they were already correct.

Verification

Availability was determined per method against four sources:

1. seatable-api@1.0.46 — external method surface, read from the package
2. dtable-sdk@5.0.17 — browser SDK
3. docs/scripts/javascript/objects/*.md — the scripting reference removed in 0d59065, recovered from git history
4. typeof checks in a running base (confirmed the column methods and updateLink / updateLinks)

Independently corroborated by the Chinese scripting manual, which states outright that the JavaScript API section does not apply to scripts.

mkdocs build --strict passes. All links checked, including the corrected insertcolumn-1 API reference.

Note

These markers make the divergence visible; they do not remove it. updateLink/updateLinks and getRows/listRows are identical in semantics and parameters and differ only in name. The scripting API already carries deprecated aliases (getRowById, addRow, modifyRow, getViews), so the mechanism for aligning names exists — it was just never used to converge with the external client. Worth a separate discussion outside this repo.

🤖 Generated with Claude Code