luci-base: add member keep_order to MultiValue

[muink]

Pull request details

Description

Add member keep_order to MultiValue.

Allow MultiValue widgets to preserve user selection order.

When enabled, selected values are saved in user selection order instead of choice order.

By default, keep_order is false and existing behavior is unchanged. When true, values are saved in the order they were selected by the user.

Screenshot or video of changes (if applicable)

Maintainer (preferred)

@systemcrash @hnyman

---

Tested on

OpenWrt version: OpenWrt 25.12.4 (r32933-4ccb782af7)
LuCI version: openwrt-25.12 branch (26.164.56110~44618b5)
Web browser(s):

---

Checklist

• This PR is not from my main or master branch 💩, but a separate branch. ✅
• Each commit has a valid ✒️ Signed-off-by: <my@email.address> row (via git commit --signoff).
• Each commit and PR title has a valid 📝 <package name>: title first line subject for packages.
• Incremented 🆙 any PKG_VERSION in the Makefile.
• (Optional) Includes what Issue it closes (e.g. openwrt/luci#issue-number).
• (Optional) Includes what it depends on (e.g. openwrt/packages#pr-number in sister repo).

[openwrt-ai]

Reviewed 1 new commit; no commit-message issues found. One inline note on missing API documentation for the new keep_order member.

---

Generated by Claude Code

[openwrt-ai]

Reviewed 1 new commit; no new issues found.

The only change since the last review adds the keep_order JSDoc @member block on CBIMultiValue, which resolves the previously raised documentation note.

---

Generated by Claude Code

[openwrt-ai]

Reviewed 1 new commit; no new issues found.

The head SHA changed since the last review, but the branch was only rebased onto a newer master; the PR's own changes to form.js and ui.js are byte-identical to the previously reviewed state.

---

Generated by Claude Code

[systemcrash]

What is the advantage to having this @muink ? I can potentially see some, but I'd like to understand the need here.

[muink]

@systemcrash The primary motivation is that UCI list values are ordered, while MultiValue currently loses that ordering information and saves values according to choice order.
This means that LuCI may rewrite UCI list entries in a different order from the original configuration, even if the user only saves the form without changing the selected values.

Preserving the original order avoids unnecessary configuration changes and better reflects user intent when list ordering is significant.
But the current implementation discards it.

This change is entirely opt-in through keep_order and does not affect existing MultiValue behavior unless explicitly enabled.

Feature requests from the real environment: fcshark-org/openwrt-fchomo#54

[openwrt-ai]

Reviewed 1 new commit; no new issues found.

The head SHA changed since the last review (9a1da6e → e2b3094), but this is a rebase onto a newer master only — the commit's own diff against its parent is byte-identical to the previously reviewed state. The three intervening ui.js changes on master (regex character-class cleanups in handleDelete/pingDevice, and the duck-typed View check in createHandlerFn's loader) do not touch UIDropdown, so there is no semantic interaction with the keep_order changes. Commit message still matches the diff, and all checks on the new head are green.

---

Generated by Claude Code

[openwrt-ai]

Reviewed 1 new commit; no new issues found.

The head SHA changed since the last review (e2b3094 → 1fc5211), but this is a rebase onto a newer master only — the commit's own diff against its parent is byte-identical to the previously reviewed state, and form.js/ui.js at the new head are unchanged relative to the old head. Commit message still matches the diff; no CI failures reported on the new head.

---

Generated by Claude Code

[openwrt-ai]

Reviewed 1 new commit; no new issues found.

The head SHA changed since the last review (1fc5211 → 5204a21), but this is a rebase onto a newer master only — the commit's own diff against its parent is byte-identical to the previously reviewed state, and form.js/ui.js at the new head are unchanged relative to the old head. No commit in the rebase range touches luci-base's ui.js or form.js, so there is no new interaction with the keep_order changes. Commit message still matches the diff, and all checks on the new head are green.

---

Generated by Claude Code

[muink]

Hi @systemcrash ,

Just checking whether you have any thoughts on this PR when you have a chance.

If you don't think this feature belongs in LuCI, that's completely fine — I'd just like to know whether there are any objections to the approach or whether I should consider an alternative implementation.

Thanks.

[openwrt-ai]

Reviewed 1 new commit; no new issues found.

---

Generated by Claude Code