feat(web): let schemas label enum dropdown options - #442
Conversation
An enum property renders as a dropdown whose option text is derived from the value — underscores replaced, title case applied. That works when the value reads as its own label and fails when it does not: "vs" renders as "Vs", and "abbrev" tells the user nothing about the "Sep 19" it produces. Schemas had no way to say otherwise, so the label was whatever the config key happened to look like. Enum dropdowns now take their option text from x-options.labels when the schema supplies it. This is not a new convention: the checkbox-group widget has read x-options.labels since it was written, with the same humanised fallback. This extends it to plain enums and to array-table columns. Display only — the option value, and so the saved config, is unchanged. The map may be partial; unlabelled values keep the humanised fallback, so every existing schema renders exactly as before. Older cores ignore x-options entirely, which means a plugin can ship labels without requiring users to upgrade first. Array-table columns get the same lookup but keep the raw value as their fallback rather than the humanised one. Those columns hold values such as ticker symbols, where "aapl" -> "Aapl" would be wrong, and they were not being humanised before this change. Verified against the running web service: with labels the hockey plugin's date dropdown reads "Sep 19 / 9/19 / 19 Sep / 19/9 / Fri Sep 19"; with the pre-change template and the same schema it falls back to "Abbrev / Numeric / Day First / ...", confirming the degradation path.
|
Warning Review limit reached
Next review available in: 40 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThe plugin configuration template now supports custom enum display labels through ChangesEnum option labels
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches 💡 1⚔️ Resolve merge conflicts 💡
📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Not up to standards ⛔🔴 Issues
|
| Category | Results |
|---|---|
| Security | 2 high |
🟢 Metrics 5 complexity · -2 duplication
Metric Results Complexity 5 Duplication -2
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
|
@coderabbitai review |
✅ Action performedReview finished.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@test/test_enum_option_labels.py`:
- Around line 21-33: The tests currently render the copied SELECT_FRAGMENT
instead of the shipped template, so they can miss production changes. Update
_render and the related tests in test_enum_option_labels.py to load and render
the production configuration template with a minimal fixture, or assert the
complete active enum-label expression in CONFIG_FORM; remove reliance on the
duplicated expression while preserving coverage of custom labels and the
fallback formatting.
In `@web_interface/templates/v3/partials/plugin_config.html`:
- Around line 582-586: Update the dynamic enum option creation in createCell()
used by addArrayTableRow so each option’s displayed text resolves the column
labels from x-options or x_options, falling back to the raw value when no label
exists. Keep the option value unchanged and match the server-rendered col_labels
behavior.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 990f2308-322e-4509-bc1d-59bf48cf7ee5
📒 Files selected for processing (4)
.github/workflows/test.ymldocs/widget-guide.mdtest/test_enum_option_labels.pyweb_interface/templates/v3/partials/plugin_config.html
…t the shipped template Both points from the CodeRabbit review on #442. array-table.js built enum <option> elements with o.textContent = opt, so a row added with "Add row" showed the raw value while the server-rendered rows above it showed the schema's label — the same column reading two different ways until the page was reloaded. Both option-building sites now go through a shared enumOptionLabel(), which mirrors the template exactly: x-options or x_options, labels map, raw value as the fallback. The tests rendered a copy of the template expression, so they could pass while production drifted. They now extract the live enum <select> block out of plugin_config.html and render that, and assert on the full value -> label map rather than substring presence. Mutation-checked, since a guard that cannot fail is not a guard: - remove the labels lookup -> 5 of 9 fail - change only the fallback to -> 2 of 9 fail option|upper (keeping the enum_labels.get call intact) - revert the JS to raw values -> 1 of 9 fails The middle case is the one the review called out as able to slip through.
# Conflicts: # .github/workflows/test.yml
2 participants
Problem
An
enumproperty renders as a dropdown whose option text is derived from the value:{{ option|replace('_', ' ')|title }}That works when the value reads as its own label, and fails when it doesn't:
vsabbrevnumeric_day_firstA schema had no way to say otherwise, so the visible label was whatever the config key happened to look like — and config keys are chosen for the API, not the UI.
Change
Enum dropdowns now take their option text from
x-options.labelswhen supplied.This is not a new convention. The
checkbox-groupwidget has readx-options.labelssince it was written, with the same humanised fallback (plugin_config.html, checkbox-group branch). This extends it to plain enums and to array-table columns.Compatibility
Array-table columns get the same lookup, but their fallback stays the raw value rather than the humanised one — those columns hold values like ticker symbols, where
aapl→ "Aapl" would be wrong. They were not humanised before this change and still aren't.Verification
Checked against the running web service on a real device, not just unit tests:
Sep 19 / 9/19 / 19 Sep / 19/9 / Fri Sep 19Abbrev / Numeric / Day First / ...(degradation path confirmed)8 new tests in
test/test_enum_option_labels.py, enrolled in CI. They render the real Jinja expression rather than a paraphrase, so dropping the lookup fails the suite. Existing template guards (test_template_targets,test_widget_scripts,test_doc_links) still pass — 12/12.Convention documented in
docs/widget-guide.md.Summary by CodeRabbit
New Features
x-options.labelsandx_options.labelsformats.Documentation
Tests