Expand a ransack_alias named in advanced-search params

[scarroll32]

Note

This PR was opened by Claude (Claude Code), acting on behalf of @scarroll32.

Closes #1728.

Why

A ransack_alias worked in a simple key (term_cont=a) but not in advanced-search params (a: { '0' => { name: 'term' } }). The simple key goes through Condition.extract, which resolves aliases before the attributes are built. The advanced params name the attribute directly, so the alias reached Attribute.new as-is, passed valid? by being allowlisted under its own name, and bound a column that does not exist. attribute_select lists ransackable_attributes, which includes the alias, so any advanced-search form on a model with an alias offered a choice that 500'd (activerecord-hackery/ransack_demo#113).

What

Condition#attributes= now expands each name through Context#resolve_aliases before building, the same lookup the simple path uses, so the two entry points agree:

• An alias to one attribute (daddy → parent_name) is built under the target name.
• An alias to a compound (term → name_or_email) becomes one attribute per segment, joined by the compound's combinator.
• An alias defined on an associated model and reached through a path (person_term on Article) expands too, since resolve_aliases already handles that.
• An explicit m in the params wins over the compound's combinator; a blank m, which a form may send after the attributes, does not wipe it.
• A name that is not an alias is built exactly as before, and a blank name keeps the name.nil? bypass that Grouping#new_condition relies on.

attribute_select is unchanged: it keeps offering the alias, and what it offers now works. The value reads back under the alias from its grouping (grouping.term_cont), as the existing #689 behaviour already did for a single-attribute alias.

Verification

• 764 examples, 0 failures on SQLite (Active Record 7.2.3.2, Ruby 3.4.9)
• 8 new examples in ransack_alias_spec.rb under "named in advanced-search params": compound alias, single association alias, alias on an associated model, blank m after the attributes, explicit m winning, alias mixed with a plain attribute, read-back from the grouping, and attribute_select still listing the alias
• RuboCop clean on the changed files

🤖 Generated with Claude Code

[Copilot]

Copilot review overview

🟡 Changes recommended

Combinator fallback currently mishandles invalid and mixed combinators.

Review effort: Balanced
Findings: 1

Open (1)

• Unknown combinators incorrectly fall back to alias combinators · New

What changed in this PR

Expands ransack_alias values supplied through advanced-search parameters.

Changes:

• Resolves aliases before building condition attributes.
• Preserves alias-derived combinators unless explicitly overridden.
• Adds advanced-search alias coverage.

File	Description
lib/​ransack/​nodes/​condition.rb	Expands aliased attributes and derives combinators.
spec/​ransack/​active_record/​ransack_alias_spec.rb	Tests advanced-search alias behavior.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[scarroll32]

Good catch, fixed in 138cd40. Condition#combinator= now records whether a non-blank value was supplied, and the alias combinator is used only when none was. An unknown m still normalises to nil and fails valid_combinator?, so the condition is dropped (or raises Invalid combinator under ransack!) like any other multi-attribute condition. Spec added for both modes.