fix(agent): authorize associate-related on the foreign collection and scope the many-to-many link

[PMerlet]

Fixes PRD-927. Ruby counterpart of PRD-922, fixed in agent-nodejs #1820.

The bug

POST /forest/:collection/:id/relationships/:relation asserted edit on the parent collection, then mutated the child one — the OneToMany branches update the child's origin key, the ManyToMany branch creates a through row.

A user with edit on companies but none on users (relation companies.users, origin key users.company_id) could reassign a users row they cannot edit. dissociate_related already authorizes the child collection since #350, so associating was the cheaper inverse of a write that required more.

The ManyToMany branch also resolved its target through Collection.get_value, which short-circuits on a primary key and never queries, so the through row was created with no scope check at all. #350 excluded that branch explicitly.

The fix, one commit per defect

1. Authorize the mutated collection. can?(:edit, context.child_collection), above unpack_id so a denied caller still gets a 403 rather than an id-validation error.
2. Scope the ManyToMany link. The target is resolved through list with match_ids(target) ∩ get_scope(child_collection), and the through row is skipped when it comes back empty.
3. Write the relation's key targets, not the primary keys. associate_many_to_many built the through record from Schema.primary_keys(...)[0] on both sides. ActiveRecord derives foreign_key_target / origin_key_target from an association's primary_key: option, so has_and_belongs_to_many :addresses, primary_key: :reference was enough to write a primary key into a column holding another key — and make_through_filter, which dissociate_related builds on, already read the targets, so associate wrote rows that dissociate could not match back. No-op wherever the targets default to the primary key.
4. Match every column of a composite key. The two OneToMany branches identified their target with a leaf on the first primary key, so on a composite-key child the update reassigned every row sharing that column, and a sibling row in scope was enough to let an out-of-scope target through. All three branches now build their filter through one target_in_scope_filter, which also stops them from drifting apart on the scope again.

Contract when the scope excludes the target

204, nothing written — as in agent-nodejs #1820 and as in the OneToMany branches, whose intersected filter simply matches no row. Pinned by a test.

Notes for the reviewer

• match_ids requires Equal/In on the child's primary key, which the leaf did not. Every datasource in the tree declares them (ActiveRecord, Mongoid, BASE_OPERATORS in hasura, STRING_OPS/NUMBER_OPS in zendesk, ID_OPS in mambu's reconcile_filter_operators!). A hand-written datasource declaring filter_operators: [] on a primary key would 500 here, but it is already broken on show and dissociate, which both go through match_ids.
• origin_value is still read on the parent without scope, as on Node — out of scope for this PRD.

Tests

edit asserted on the child and never on the parent in all three branches, 403 raised before the target id is parsed, the scope-intersected filter, no link when the target is out of scope, and two new fixtures: a ManyToMany whose keys target code / reference, and a composite-key note collection reached both through a OneToMany and through a note_user through collection.

Every assertion was checked against the faulty implementation it guards — permission back on the parent, scope dropped, guard removed, key targets and the shared filter reverted — and each mutation is caught in a couple of seconds.

Permission and scope assertions compare collection names inside a have_received do |...| block instead of passing the collection to having_attributes: rspec formats the decorator chain on failure, and the example then takes minutes and reports no failure at all. #353 hit the same wall.

849 examples, 0 failures on forest_admin_agent; bundle exec rubocop clean over the package.

🤖 Generated with Claude Code

[linear-code]

PRD-927

[qltysh]

Coverage Impact

This PR will not change total coverage.

Modified Files with Diff Coverage (1)

Rating	File	% Diff	Uncovered Line #s
	...rest_admin_agent/routes/resources/related/associate_related.rb	100.0%
	Total	100.0%

🚦 See full report on Qlty Cloud »

🛟 Help

• Diff Coverage: Coverage for added or modified lines of code (excludes deleted files). Learn more.

• Total Coverage: Coverage for the whole repository, calculated as the sum of all File Coverage. Learn more.

• File Coverage: Covered Lines divided by Covered Lines plus Missed Lines. (Excludes non-executable lines including blank lines and comments.)

  • Indirect Changes: Changes to File Coverage for files that were not modified in this PR. Learn more.

[forest-bot]

🎉 This PR is included in version 1.38.2 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀