Use activerecord store for the json column

[strivedi183]

Use store accessors for user preferences

Toward #516 — covers users.preferences; the other jsonb columns are deliberately left for follow-ups (see below).

Summary

users.preferences was written wholesale by both update paths, so saving one setting silently destroyed others — collapsing the sidebar wiped an explicitly chosen dark mode, and the settings form erased every key outside its permit list. Both paths now write per-key through typed store accessors, so whole-hash replacement is no longer expressible.

• Sidebar toggle PATCHes only nav_closed; theme radios emit scalar dark_mode; regression tests prove sibling keys and nested preferences[:feature] survive every write. Saved preferences stop disappearing.
• New "AI backends" section in settings: a Default / RubyLLM / Built-in SDK radio row per chat-capable driver, rows derived from APIService.drivers so new drivers appear automatically. The RubyLLM radio stays disabled until AIBackend::RubyLLM.supports_driver? covers that driver, so the UI never offers a choice routing can't honor. Choices are stored but not read yet — routing arrives with RubyLLM phased migration feature-flagged #775.
• Resolution is symmetric: explicit per-driver choice → explicit use_ruby_llm opinion → site default (options.yml, ENV-controlled) → off. use_ruby_llm ships false and nothing in this repo turns it on; to try RubyLLM on one driver, opt in per user (user.features[:openai_ai_backend] = "ruby_llm"). The wiring commit message carries the recipe, and both override directions are pinned by tests.
• Writes through user.features[] are minimized: only the <driver>_ai_backend choices plus use_ruby_llm are writable; every other option.yml flag raises on read and write, so deployer-scoped flags stay site-controlled.

This lays the per-user opinion storage that the RubyLLM migration (#740) needs — the settings UI, User#ruby_llm?(driver) reader, and ballot box are ready for #775 to consume. It also answers the per-user-toggle question raised on #744 (leverage User.preferences, keep the options.yml flag as the inheritable default).

Follow-ups

• The remaining nine jsonb columns from Use activerecord store for the json columns #516 (credentials.properties, runs.required_action/last_error/tools/file_ids, steps.details/last_error, assistants.tools, messages.content_tool_calls) — whole-object writes need no partial-write pattern; each can adopt this pattern when it earns it.

[strivedi183]

Context for anyone connecting this to the earlier RubyLLM work:

• The safe-writes half grew out of Use activerecord store for the json columns #516: users.preferences was silently erasing sibling keys on every save, and RubyLLM phased migration feature-flagged #775's Phase 1 hit the same bug independently (hence its deep-merge patch). This PR fixes it at the root with per-key accessor writes, so that patch is superseded.
• The ballot box is the per-user toggle we discussed on Add RubyLLM as alternative AI backend behind feature flag. #744 — store the opinion in User.preferences, keep the options.yml flag as the inheritable default, site default steers silent users only. @fluxgravity @mattlindsey this is the piece RubyLLM phased migration feature-flagged #775's later phases can consume: per-driver choices land as <driver>_ai_backend values via user.features[]=, and User#ruby_llm?(driver) is the reader.
• On Use activerecord store for the json columns #516 scope: the issue says "json columns" (all ten). This covers users.preferences and deliberately leaves the other nine (they're written as whole objects, so they don't need this pattern yet) — happy to follow up column by column if incremental is easier to review.
• One deliberate omission: value validation on dark_mode was drafted and dropped during review — the hole predates this PR and nothing here worsens it. Happy to add it as a follow-up when there's a second writer.

[mattlindsey]

@strivedi183 Nice catch. Is this ready to merge?

[mattlindsey]

Actually just to be picky:

1. Alignment:

2. Since the end user doesn't actually know what the 'Site Default' is set to (RubyLLM true or false) should we display that somewhere so they know what they're getting if they choose that checkbox?

3. You are probably correct in this, but I'm a little unsure why there's an extra 'feature' level in the preferences field.

Why

  preferences:
   {dark_mode: "system", feature: {openai_ai_backend: nil, anthropic_ai_backend: nil, gemini_ai_backend: "sdk"}},

Instead of:

  preferences:
   {dark_mode: "system", openai_ai_backend: nil, anthropic_ai_backend: nil, gemini_ai_backend: "sdk"},

4. Strings should display both English and German. 

[strivedi183]

Actually just to be picky:

1. Alignment:

2. Since the end user doesn't actually know what the 'Site Default' is set to (RubyLLM true or false) should we display that somewhere so they know what they're getting if they choose that checkbox? 3. You are probably correct in this, but I'm a little unsure why there's an extra 'feature' level in the preferences field.

Why

  preferences:
   {dark_mode: "system", feature: {openai_ai_backend: nil, anthropic_ai_backend: nil, gemini_ai_backend: "sdk"}},

Instead of:

  preferences:
   {dark_mode: "system", openai_ai_backend: nil, anthropic_ai_backend: nil, gemini_ai_backend: "sdk"},

4. Strings should display both English and German. 

Hey @mattlindsey , thanks for the quick reply!

For 1)

I uploaded an older screenshot and missed that I uploaded an older incorrect one, sorry about that.

For 2)

But also, I hope it answers the other question on the site default. I just copied the color theme pattern above it, with the dark/light/system.

I am ok changing it if you want, it was just a starting point so I am not committed to it.

For 3)

The feature level is already the way it works in the code base. It's the app's existing storage layout, not something introduced here. Feature.enabled? reads the nested key directly:

# app/models/feature.rb (unchanged from main)
Current.user&.preferences&.dig(:feature, feature.to_sym)

Any per-user opinion that Feature.enabled? can see has to live under that key. Meanwhile, store_accessor is flat by construction. It generates accessors for top-level keys only, so store_accessor :preferences, :"feature.openai_ai_backend" would create a literal flat key named "feature.openai_ai_backend", not nesting, see store_accessor in the Rails 8.1 API docs, or reproducible in a console:

User.store_accessor(:preferences, :"feature.openai_ai_backend")
u = User.new
u.public_send("feature.openai_ai_backend=", "sdk")
u.preferences # => {"feature.openai_ai_backend" => "sdk"}   # literal flat key, no nesting

So reaching preferences[:feature][name] can't be expressed with store_accessor, which is why the User::Features hand-writes []/[]= so writing to the nested location because that's where the existing reader looks.

That said, I do have some ideas to flatten this if you all think it is a good idea. The User::Features API (user.features[:openai_ai_backend]) stays the same either way, only the storage underneath moves:

a. Extract a dedicated JSONB column (features or feature_overrides) with top-level keys, and point the reader at it:

# user.feature_overrides => { openai_ai_backend: "sdk" }
# feature.rb reader becomes:
Current.user&.feature_overrides&.dig(feature.to_sym)

Keeps UI preferences and feature opinions in separate columns but needs a migration.

b. Flatten the keys inside preferences where the User::Features writes them flat:

# today:  preferences => { dark_mode: "system", feature: { openai_ai_backend: "sdk" } }
# flat:   preferences => { dark_mode: "system", openai_ai_backend: "sdk" }
# feature.rb reader becomes:
Current.user&.preferences&.dig(feature.to_sym)

No migration, but UI preferences and feature opinions share one hash. Happy to do either as a follow-up if you'd prefer flat storage.

For 4)

Fixed, the new strings now live in the en/de locales and render through t() like the rest of the form (German included; driver names stay proper nouns). Full disclosure, I had AI write the translations, so not sure if they are accurate.

Thank you for the feedback and let me know if there is anything else, either with my responses or the PR!

[mattlindsey]

Thanks for the explanations! Everything looks fine to me, so if you take it off Draft I'll merge it. Thanks again.