fix: support radio inputs in admin system config form #724

Merged

jmiller merged 5 commits from fix/admin-config-radio into main 2026-07-04 19:01:40 +00:00

Conversation 1 Commits 5 Files Changed 7

+61 -13

jmiller commented 2026-07-04 18:12:11 +00:00

Owner

Copy Link

Copy Source

Problem

The admin Site Administration → Settings page threw a JS error, aborting all config-form init:

Error: Unsupported config form value mapping for INPUT (name=instance.landing_page.Mode,type=radio)

The system config form mapper (web_src/js/features/admin/config.ts) only handled checkbox, text, textarea, and datetime-local elements. The fork's landing_page.tmpl introduced type="radio" inputs for the Mode field, so fillFromSystemConfig() fell through to unsupportedElement() and threw.

Fix

Add radio support in both directions:

• Fill: check only the option whose value equals the config value.
• Collect: return the checked option's value; skip/null out unchecked radios in both collect paths so a group resolves to exactly one value (and unchecked options don't leak into the fallback pass).

Tests

• config.test.ts: added a radio-group sub-key case (landing.Mode = explore); full assertion object unchanged otherwise, proving no regression to existing element types.
• npx vitest run web_src/js/features/admin/config.test.ts → 1 passed.

Notes

• Not included: unrelated .sublime-project/profile.ps1 deletions, no lockfile committed.
• The collation warnings reported alongside this JS error are a separate DB-state issue (fixed via admin Self-Check → Convert), not addressed here.

## Problem The admin **Site Administration → Settings** page threw a JS error, aborting all config-form init: ``` Error: Unsupported config form value mapping for INPUT (name=instance.landing_page.Mode,type=radio) ``` The system config form mapper (`web_src/js/features/admin/config.ts`) only handled `checkbox`, `text`, `textarea`, and `datetime-local` elements. The fork's `landing_page.tmpl` introduced `type="radio"` inputs for the Mode field, so `fillFromSystemConfig()` fell through to `unsupportedElement()` and threw. ## Fix Add radio support in both directions: - **Fill:** check only the option whose `value` equals the config value. - **Collect:** return the checked option's `value`; skip/null out unchecked radios in both collect paths so a group resolves to exactly one value (and unchecked options don't leak into the fallback pass). ## Tests - `config.test.ts`: added a radio-group sub-key case (`landing.Mode` = `explore`); full assertion object unchanged otherwise, proving no regression to existing element types. - `npx vitest run web_src/js/features/admin/config.test.ts` → **1 passed**. ## Notes - Not included: unrelated `.sublime-project`/`profile.ps1` deletions, no lockfile committed. - The collation warnings reported alongside this JS error are a separate DB-state issue (fixed via admin Self-Check → Convert), not addressed here.

jmiller added 1 commit 2026-07-04 18:12:12 +00:00

fix: support radio inputs in admin system config form ... 982e45a56e

The system config form JS (config.ts) only mapped checkbox, text, textarea, and datetime-local elements. The fork landing_page.tmpl uses radio inputs for the Mode field, so fillFromSystemConfig() hit unsupportedElement() and threw, aborting all JS init on the admin settings page.

Add radio handling in both directions: fill checks the option whose value matches the config value; collect returns the checked option's value and skips/nulls unchecked radios so a group resolves to exactly one value. Adds a radio-group test case.

jmiller added 1 commit 2026-07-04 18:15:16 +00:00

fix: preserve server-rendered radio default when config value is empty ... efb0433412

LandingPageType.Mode defaults to "" (Go zero value), and the template renders the home radio as checked for an empty Mode. The initial radio fill would evaluate home.checked = ("home" === "") = false, unchecking the default on a fresh install. Skip assignment when the config value is empty so the server-rendered selection is preserved. Adds a test for the empty-value case.

jmiller reviewed 2026-07-04 18:15:44 +00:00

jmiller left a comment

Author

Owner

Copy Link

Copy Source

Self-review before merge.

Reviewed:

• Radio branches added symmetrically in assignConfigValueToFormElement and collectConfigValueFromElement, ordered consistently (after checkbox, before datetime-local).
• Collect paths (collectConfigSubValues + fallback loop in collectToFormData) skip/null unchecked radios, so a group resolves to exactly one value and doesn't leak into the second pass.
• No import changes; purely additive branches, no compile/type concerns.

Bug caught and fixed during review: LandingPageType.Mode defaults to "", and the template renders the home radio checked for an empty Mode. The initial fill would have unchecked that default ("home" === "" → false). Fixed by skipping assignment when the config value is empty, preserving the server-rendered selection. Added a regression test for the empty-value case.

Tests: npx vitest run web_src/js/features/admin/config.test.ts → 1 passed (both non-empty and empty-default radio groups asserted).

Self-review before merge. **Reviewed:** - Radio branches added symmetrically in `assignConfigValueToFormElement` and `collectConfigValueFromElement`, ordered consistently (after checkbox, before datetime-local). - Collect paths (`collectConfigSubValues` + fallback loop in `collectToFormData`) skip/null unchecked radios, so a group resolves to exactly one value and doesn't leak into the second pass. - No import changes; purely additive branches, no compile/type concerns. **Bug caught and fixed during review:** `LandingPageType.Mode` defaults to `""`, and the template renders the `home` radio checked for an empty Mode. The initial fill would have unchecked that default (`"home" === ""` → false). Fixed by skipping assignment when the config value is empty, preserving the server-rendered selection. Added a regression test for the empty-value case. **Tests:** `npx vitest run web_src/js/features/admin/config.test.ts` → 1 passed (both non-empty and empty-default radio groups asserted).

jmiller added 1 commit 2026-07-04 18:37:00 +00:00

ci: allow fix/patch branches to target main and guard missing manifest ... b252e9569f

Branch policy in pr-check.yml only allowed fix/* and patch/* to target dev/rc, blocking fix/* PRs to main despite the documented policy. Allow fix/* -> main and patch/* -> main. Also guard the Detect platform step for a missing .mokogitea/manifest.xml (removed in favor of the metadata API) so it no longer aborts the Validate PR job under set -e.

jmiller added 1 commit 2026-07-04 18:46:41 +00:00

fix: remove dangling mcp-mokogitea-api submodule gitlink ... fc234bc911

The tree carried a gitlink at mcp-mokogitea-api (mode 160000) with no .gitmodules entry, so git submodule update --init --recursive failed with exit 128 at checkout, breaking every PR build/release job. mcp-mokogitea-api is a separate repo, not a submodule; remove the gitlink from the index (keeping the local working-tree clone) and gitignore the path so it can't be re-added.

jmiller added 1 commit 2026-07-04 18:53:21 +00:00

ci: no-op PR RC Release when updates.xml is absent ... aea4370845

The RC release workflow drives a Joomla-style updates.xml update stream. On a generic repo with no updates.xml, the Determine RC version step ran sed on a missing file and aborted under set -e (exit 2). Detect updates.xml presence and gate the update-stream steps (edit/create-release/commit) on it so the job succeeds and no-ops when there is nothing to package.

jmiller merged commit cb9516b79b into main 2026-07-04 19:01:40 +00:00

jmiller deleted branch fix/admin-config-radio 2026-07-04 19:01:41 +00:00

Sign in to join this conversation.

Reviewers

No Reviewers

jmiller

Labels

Clear labels

breaking-change

Breaking API or behavior change

ci-cd

CI/CD pipeline changes

config

Configuration changes

dependencies

Dependency updates

deploy-failure

Deployment failed

docker

Docker/container changes

documentation

Documentation changes

feature: wiki

Wiki system enhancements

good first issue

Good for newcomers

health-check

Repo health check result

help wanted

Extra attention needed

mokostandards

Related to MokoStandards framework

push-failure

Git push operation failed

security

Security vulnerability or hardening

size/l

200-500 lines changed

size/m

50-200 lines changed

size/s

10-50 lines changed

size/xl

500+ lines changed

size/xs

< 10 lines changed

standards-drift

Deviates from MokoStandards

standards-update

MokoStandards compliance update

sync-failure

Sync or mirror failed

tech-debt

Technical debt and TODO/FIXME items

upstream

upstream

Inherited from upstream Gitea

work-in-progress

Draft or incomplete work

bug

Something is not working

duplicate

This issue or pull request already exists

enhancement

New feature

help wanted

Need some help

invalid

Something is wrong

question

More information is needed

wontfix

This won't be fixed

No labels

Priority -

Type -

Milestone

No items

No Milestone

Assignees

Clear assignees

jmiller (Jonathan Miller) moko-deploy (Moko Deploy Bot)

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: MokoConsulting/MokoGitea-Fork#724