Laravel Restify Laravel Package

Getting Started

Start by reading the authorization contract before wiring up any UI: attach and sync operations are policy-driven, and as of 10.4.62 they fail closed when no parent policy is found. The first thing to verify in a new install is that the parent model has a policy with the ability the package checks (commonly an attach/update-style ability) and that the policy is registered in your AuthServiceProvider or auto-discovered by convention.

Minimal first use case:

1. Install the package and publish any config/service-provider bindings it exposes.
2. Create a policy for the parent model and implement the attach ability.
3. Call the package’s attach or sync action from a controller or form request, passing the parent model and the related IDs.
4. Assert the happy path returns success and the failure path returns a 403 when the policy is missing or denies.

Where to look first in the codebase: the policy resolution path (how the parent policy is located), the related-ID resolver (which now applies global scopes and soft deletes), and the transaction wrapper (which now uses the model’s own connection). Those three areas account for every change in 10.4.62. In 10.4.67, also check pivot key handling: the package now skips the primary key tiebreaker on pivots without a declared key.

Implementation Patterns

Policy-backed attach/sync. Treat the parent policy as a required dependency, not an optional nicety. In tests, create the policy explicitly; in production, add a boot-time or CI check that every model exposing attach/sync has a corresponding policy. Because the package now fails closed, a missing policy surfaces as an authorization failure rather than a silent write, which is the behavior you want — but it means policy coverage becomes part of your deployment checklist.

Custom attachers own their authorization. If you register a custom attacher to handle special relationship types, the package’s built-in policy check is bypassed. Wrap the custom logic in an explicit Gate::authorize() or policy call inside the attacher. This is documented behavior, but it is the easiest place to accidentally reintroduce an authorization hole.

Prefer sync for declarative forms, attach for incremental actions. Sync replaces the related set and is a good fit for “save this form’s selections” flows. Attach is additive and fits “add these items” actions. Both now resolve related IDs through the related model’s query builder, so the IDs you pass are subject to that model’s global scopes and soft-delete rules.

Design around scoped ID resolution. Since global scopes and soft deletes are applied when resolving related IDs, an ID that exists in the database but is hidden by a tenant scope, an “active only” scope, or a soft delete will not resolve. Validate incoming IDs against the same scoped query the package uses, or explicitly allow trashed/global records where the package exposes a flag. This prevents “valid ID rejected” bugs that only appear for scoped or trashed records.

Respect per-model connections. Write transactions now run on the model’s own connection. If your parent and related models live on different connections, do not assume the attach/sync is atomic across both. For cross-connection workflows, perform the operation on the owning connection and handle compensation logic yourself, or restructure so both models share a connection.

Handle pivots without declared keys. As of 10.4.67, pivot queries skip the primary key tiebreaker when the pivot has no declared key (#814). If you use a custom pivot model or a pivot table without an id/primary key, attach/sync no longer assumes a key exists for tiebreaking. This fixes an edge case, but it also means deterministic ordering is not guaranteed by a surrogate key. If ordering matters, define an explicit order column or primary key on the pivot model/table.

Integration tips.

• Use form requests to validate that related IDs are arrays of scalars before they reach the resolver.
• Catch authorization exceptions at the controller boundary and map them to 403 responses consistently with the rest of your API.
• In feature tests, assert both the authorization outcome and the database state; the fail-closed change means a previously passing test without a policy will now fail, which is a useful signal.
• When seeding demo data, seed the policies too, or attach/sync calls in seeders will fail closed.
• If you maintain custom pivot models, verify $primaryKey, $incrementing, and key type reflect the actual pivot table so the package’s tiebreaker logic matches your schema.

Gotchas and Tips

Missing policy is now a hard failure. Any attach or sync path without a resolvable parent policy will fail closed. If you upgraded and suddenly see 403s in code that used to work, the cause is almost certainly a missing or misnamed policy ability, not a broken relationship.

Custom attachers silently skip authorization. The package cannot enforce policy checks inside your custom attacher. Audit every registered custom attacher and add explicit authorization. Consider a shared base class or trait that performs the policy check so new attachers cannot forget.

Global scopes can make valid IDs “disappear.” Related-ID resolution now honors global scopes. Debugging tip: reproduce the resolution with Model::withoutGlobalScopes()->find($id) versus the default query. If the ID resolves only without scopes, the attach/sync is correctly rejecting it — fix the scope or the caller, not the package.

Soft-deleted records are excluded by default. Unless the package’s API gives you an explicit include-trashed option, soft-deleted related models will not resolve. This is usually correct, but it breaks “re-attach a previously removed item” flows. Decide whether restoration should happen before attach/sync, and make that explicit in your domain logic.

Transactions follow the model, not your default connection. If you rely on DB::transaction() around a call while the model uses a different connection, the package’s internal write transaction is on the model’s connection and your outer transaction may not cover it. Check $model->getConnectionName() when diagnosing partial-write behavior in multi-database applications.

Pivots without a declared key no longer get a primary-key tiebreaker. In 10.4.67 the package skips that tiebreaker (#814), which is what you want for keyless pivots but can change ordering behavior for custom pivot models that previously appeared to work by accident. If sync results or duplicate handling look nondeterministic on a pivot table without an id, add a real key or an explicit order column rather than relying on implicit ordering.

Extension points to review after upgrading.

• The policy ability name and resolution mechanism, if you override it.
• Custom attacher registrations, for the authorization gap described above.
• Any query customizations you applied to related-ID resolution, since global scopes and soft deletes are now applied before your logic runs.
• Connection configuration for models using non-default connections, since transaction placement changed.
• Pivot model key configuration if you use custom pivots or pivot tables without a declared primary key (10.4.67).

Debugging checklist for a failed attach/sync. Confirm a parent policy exists and allows the action; confirm the related IDs resolve under the related model’s global scopes and soft-delete state; confirm both models’ connections and whether cross-connection atomicity was assumed; confirm whether a custom attacher handled the request and skipped authorization; and if the pivot has no declared key, confirm your pivot model’s key/order configuration rather than expecting a primary-key tiebreaker. Those checks cover the behavior changed across 10.4.62 and 10.4.67.