fix(agent): authorize create with a linked one-to-one on the foreign collection

[PMerlet]

Fixes PRD-921. Ruby counterpart of PRD-916, fixed in agent-nodejs #1819.

The bug

POST /forest/:collection with a linked OneToOne / PolymorphicOneToOne relation asserted only add on the parent collection, then updated the foreign collection with no authorization and no scope:

condition_tree = ConditionTreeFactory.match_records(foreign_collection, [primary_key_values])
foreign_collection.update(context.caller, Filter.new(condition_tree: condition_tree), patch)

A user with add on books but no edit on passports could rewrite the foreign key of an arbitrary passport — stealing it from its owner — including a passport outside their scope. Worse than the Node instance on two counts: Node at least asserted edit (on the wrong side) and kept the writes scope-bounded.

The fix

• Assert edit on the foreign collection, once per linked one-to-one relation, and before the parent record is created — a denied link writes nothing at all, and a denial on one relation no longer lets writes on the others through. The parent-side add check is unchanged.
• Intersect get_scope(foreign_collection) into the update filter, mirroring create_new_one_to_one_relationship in update_related.rb (PRD-908, fix(agent): scope and authorize related write routes on the mutated collection #350).
• Resolve everything the linking pass needs — the edit assertion, the scope, and the unpacked linked id — in a single pre-create pass, and carry it in the relation hash. get_scope reads the forest.rendering cache that nothing earlier in this route warms, and unlike can? it has no permission_system? bypass; leaving it below create meant a cold cache, a Forest API 5xx or an unresolvable team/user raised after the parent row was committed, so the 500 the caller retried duplicated the parent. Same shape for a malformed packed id. The "a rejected link writes nothing at all" invariant now holds for failed lookups, not only for denied permissions.
• Single linked_one_to_one_relations helper feeding both the permission pass and the linking pass, so widening the guard on one side can no longer silently drop the check on the other.

Observable contract when the scope excludes the target

A caller linking a foreign record outside their scope gets a 201 with the parent created and the relation absent — the intersected filter matches no row and entity&.update! is a no-op, indistinguishable from linking an id that does not exist. This is deliberate: it is what agent-nodejs #1819 and create_new_one_to_one_relationship in update_related.rb both do, and the PRD prescribes the mechanism without asking for a 403. Counting first to raise ForbiddenError would diverge from Node and cost an extra query; the contract is instead pinned by a test and stated at the call site.

Two defects on the rewritten lines, fixed along the way and each pinned by a test — flagging them explicitly as they sit outside the strict scope of the PRD:

• the linked id was unpacked against context.collection (the parent) while the match_records that follows targets the foreign collection, so the filter carried the wrong primary key names as soon as the two sides disagreed;
• a one-to-one relationship carrying data: null raised a NoMethodError (value['data']['id']); it is now ignored, matching Node's linked !== null.

Deliberate divergence from Node

Node runs two updates (null the old foreign-key owner, then claim the new one); this route keeps its single update. On a create, origin_value is the id of a record that has just been born, so no foreign record can already carry it — Node's first update is a no-op costing one query. The PRD notes the same, and it has no bearing on the authorization gap.

Tests

store_spec.rb: scope intersected (one-to-one and polymorphic), a denied edit creating neither parent nor link, 403 raised before the linked id is parsed (the invariant PRD-908 established on update_related.rb), a failed scope lookup and a malformed linked id each creating neither parent nor link, the silent no-op when the scope excludes the target, data: null ignored, and the parent-side add check pinned so removing it would not go unnoticed.

The polymorphic fixture carries origin_type_value: 'Person::Legacy' on a collection named person, so the addressable_type assertion pins context.collection.name as the source of the type column instead of passing under either candidate.

Permission assertions go through a collected [action, collection_name] list rather than having_attributes on the collection instances: on failure, rspec inspects the decorator chain and the run hangs instead of reporting.

Every new assertion was checked against the faulty implementation it guards — the pre-fix route, unpack_id hoisted back above the permission check, the parent collection restored as the unpack target, get_scope and unpack_id dropped back below create, and schema.origin_type_value swapped in for the collection name — and each mutation is caught.

842 examples, 0 failures on forest_admin_agent; rubocop clean.

🤖 Generated with Claude Code

Note

Authorize edit on linked one-to-one foreign collections before creating a record

• The Store#handle_request action now resolves linked one-to-one (and polymorphic one-to-one) relations from the request payload before creating the main record, and calls can?(:edit) on each foreign collection, aborting if any permission is denied.
• link_one_to_one_relations is refactored to accept a precomputed relations array and now unpacks the foreign record's primary key against the foreign collection (not the current collection), fixing incorrect record matching.
• Scope from permissions.get_scope is intersected into the update filter for each foreign collection, ensuring scoped access controls are respected during relation linking.
• One-to-one relationships with nil data ids are skipped rather than processed.

Changes since #353 opened

• Added authorization checks for one-to-one linked relations during record creation [7a1a75c]
• Removed inline comments from test files [7a1a75c]

^{Macroscope summarized 222e53d.}

[linear-code]

PRD-921

[qltysh]

All good ✅

[qltysh]

Coverage Impact

This PR will not change total coverage.

Modified Files with Diff Coverage (1)

Rating	File	% Diff	Uncovered Line #s
	...t_admin_agent/lib/forest_admin_agent/routes/resources/store.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.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀