A GM may read their own campaign's AI settings while per-campaign AI is off (#777) #782
Loading…
Reference in a new issue
No description provided.
Delete branch "build/777-ai-settings-read"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes #777. Owner, 2026-09-23: allow it.
The change
GET /api/campaigns/{id}/ai-settingsno longer answers 403 while the instance switch (D25) is off. It returns the stored settings with a newoverrides_allowed: bool. Writes are unchanged —PUTandDELETEstill refuse while the switch is off.require_gmis unchanged, so a player is still refused either way.No key can reach the response. I read
_campaign_ai_responserather than take it on trust: the only thing it ever says about a key isllm_api_key_set/asr_api_key_set, both booleans. The tests assert the key string is absent from the body, and from the page's DOM.What it fixes on the page
IS-314draws the AI panel's switched-off states apart, and while the read was refused the page could not tell them apart, so #776 shipped them as one sentence covering both. Now:A network failure keeps the old combined wording, since a failed request genuinely cannot tell the two apart.
The page also stops making a separate
fetchInstanceSettingscall just to learn the switch's state:overrides_allowedon the one response is the source of truth.Tests
test_campaign_ai_settings.py: 35 passed (+7).test_the_instance_toggle_gates_the_read_tooasserted the old 403 and was wrong by decision; it is replaced bytest_the_read_survives_the_instance_toggle_but_the_write_does_not, which asserts both halves — the read answers, and the PUT still 403s. Plus: stored overrides readable while off with no key in the body;overrides_allowedtrue when on; a player refused while off.test_backup_client_version.py, readsdocker-compose.ymlfrom the repo root, which the backend-only bind mount does not contain; CI runs it with the full checkout.ruff checkandruff format --check(0.4.4) clean.🤖 Generated with Claude Code
The instance switch previously gated the GET too, so a GM whose group had configured per-campaign AI before an admin turned the feature off lost visibility into what was stored. Per owner decision (2026-09-23), reads now succeed regardless of the switch; writes stay refused. Backend: GET /api/campaigns/{id}/ai-settings drops the _require_campaign_ai_overrides_enabled guard and returns a new overrides_allowed field so callers can tell "never set up" apart from "set up, then switched off" without a 403. The PUT/DELETE guards are unchanged. Frontend: CampaignSettingsRecording reads overrides_allowed from the GET response instead of a separate instance-settings fetch inferred from a 403 (IS-314). Off + nothing stored shows no panel; off + stored names the summariser's and transcriber's address and model (never a key's value, only whether one is set); on shows the normal editable form. A network error falls back to the old merged wording, since there is no answer to distinguish the two off-states from. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>