Draft
Conversation
Contributor
Preview deployments |
Contributor
Realm Server Test Results 1 files 1 suites 19m 19s ⏱️ Results for commit e28a3fe. |
Contributor
Host Test Results 1 files 1 suites 2h 37m 28s ⏱️ Results for commit e28a3fe. |
backspace
force-pushed
the
routing-types-and-validation-cs-10052
branch
from
e28a3fe to
80ebed7
Compare
Adds a generic `sameRealm: boolean` option to `linksTo()` that, when set, makes `LinksTo.validate` reject a linked card whose realm does not match the containing card's realm. The check uses the existing `getRealmURLString` helper (now exported from field-support) so it works whether the parent is a FieldDef (via [realmContext]) or a CardDef (via meta.realmURL); it skips silently when either realm is unknown so synthetic in-memory construction is unaffected. Apply the option to `RoutingRuleField.instance` so RealmConfig hostRoutingRules can only reference cards within the same realm — the constraint called out in the Host Mode Routing MVP spec. Tests for the validation path land in a follow-up; CI will exercise the existing instance-of failure case to confirm no regression in the surrounding LinksTo.validate logic. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Add a unit test in card-basics-test that exercises the new sameRealm option on linksTo across three cases: - same-realm assignment is accepted - cross-realm assignment throws the expected validation error - assignment is allowed when the parent has no realm meta (the silently-skip-if-unknown safety valve for synthetic in-memory construction) Realm meta is injected on the synthetic test cards by setting the exported `[meta]` symbol directly, mirroring the pattern used in serialization-test.gts. Endpoint-level coverage of the same path will land with the planned defense-in-depth /_config 400 commit. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Mirror the linksTo plumbing on LinksToMany so any future card that needs a same-realm constraint on a multi-link gets it from the same RelationshipOptions flag. Each element in the array runs through the same realm check; nulls and not-loaded references are skipped (as they already are for the existing instance-of and FileDef-id checks). No current consumer — RoutingRuleField uses linksTo, not linksToMany — but this keeps the option behaviour symmetric across the two relationship field types. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Renders the rule as `<path> → <instance.cardTitle>`, using @fields.instance @Format='atom' to delegate the linked card's display. Edit / embedded / fitted templates are intentionally deferred to the realm-config UI work in CS-10056. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Surface sameRealm on the Field interface and pass it through to the chooseCard call as preselectConsumingRealm so the card picker opens with the consuming realm's filter on by default. The user can still deselect the filter and pick a card from another realm — schema-level validate.same-realm rejects the assignment in that case, so this is purely a UX nudge that steers users toward valid candidates. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
backspace
force-pushed
the
routing-types-and-validation-cs-10052
branch
from
80ebed7 to
a315e93
Compare
Reverts the sameRealm option on linksTo / linksToMany. CS-10052 was treating "routing rules must reference same-realm cards" as a schema-level constraint, but the rule is a UX/product expectation, not a security boundary — Boxel supports cross-realm card loads, and the failure modes for a cross-realm rule (403s for viewers, weird published-realm bundles) are confusing rather than dangerous. The right home for the constraint is a custom edit template on RealmConfig (or RoutingRuleField) that hard-scopes the picker to the consuming realm. That work belongs with CS-10056, the realm-config edit UI ticket. Reverts: - sameRealm? on RelationshipOptions / FieldConstructor / Field interface - LinksTo / LinksToMany sameRealm field, constructor wiring, validate hook - RoutingRuleField.instance: sameRealm: true - LinksToEditor preselectConsumingRealm wiring - card-basics-test sameRealm test case - getRealmURLString export (back to private in field-support.ts) The atom template on RoutingRuleField stays — that's an independent rendering improvement. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
Host Test Results 1 files 1 suites 1h 43m 7s ⏱️ Results for commit 62ac830. |
backspace
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.