Relationships
Nova ships with a variety of fields out of the box, including fields for text inputs, booleans, dates, file uploads, Markdown, and more.
In addition to the variety of fields we’ve already discussed, Nova has full support for all of Laravel’s relationships. Once you add relationship fields to your Nova resources, you’ll start to experience the full power of the Nova dashboard, as the resource detail page will allow you to quickly view and search a resource’s related models:
HasOne
The HasOne
field corresponds to a hasOne
Eloquent relationship. For example, let’s assume a User
model hasOne
Address
model. We may add the relationship to our User
Nova resource like so:
Like other types of fields, relationship fields will automatically “camel case” the displayable name of the field to determine the underlying relationship method / attribute. However, you may explicitly specify the name of the relationship method by passing it as the second argument to the field’s make
method:
HasOneOfMany
The HasOne
relationship field can be transformed into an “has one of many” Eloquent relationship using the ofMany
method. For example, let’s assume a User
model hasMany
Post
models. We may add the “has one of many” relationship to our User
Nova resource like so:
HasMany
The HasMany
field corresponds to a hasMany
Eloquent relationship. For example, let’s assume a User
model hasMany
Post
models. We may add the relationship to our User
Nova resource like so:
Once the field has been added to your resource, it will be displayed on the resource’s detail page.
When defining HasMany
relationships, make sure to use the plural form of the relationship so Nova can infer the correct singular resource name:
HasOneThrough
The HasOneThrough
field corresponds to a hasOneThrough
Eloquent relationship. For example, let’s assume a Mechanic
model has one Car
, and each Car
may have one Owner
. While the Mechanic
and the Owner
have no direct connection, the Mechanic
can access the Owner
through the Car
itself. You can display this relationship by adding it to your Nova resource:
HasManyThrough
The HasManyThrough
field corresponds to a hasManyThrough
Eloquent relationship. For example, a Country
model might have many Post
models through an intermediate User
model. In this example, you could easily gather all blog posts for a given country. To display this relationship within Nova, you may add it to your Nova resource:
BelongsTo
The BelongsTo
field corresponds to a belongsTo
Eloquent relationship. For example, let’s assume a Post
model belongsTo
a User
model. We may add the relationship to our Post
Nova resource like so:
You may customize the resource class used by the relation field by providing the second and third arguments of the make
method, which define the name of the relationship and the underlying Nova resource class:
Peeking at BelongsTo Relationships
When hovering over a BelongsTo
link when viewing the index or detail views, Nova will show a small card allowing you to “take a peek” at the linked relation:
Preventing Peeking at BelongsTo
Relationships
Relationship peeking is enabled by default; however, you can prevent the user from peeking at the relation using the noPeeking
helper on your BelongsTo
field:
You may also use the peekable
method to determine whether the user should be allowed to peek at the relation:
Nullable Relationships
If you would like your BelongsTo
relationship to be nullable
, you may simply chain the nullable
method onto the field’s definition:
Title Attributes
When a BelongsTo
field is shown on a resource creation / update page, a drop-down selection menu or search menu will display the “title” of the resource. For example, a User
resource may use the name
attribute as its title. Then, when the resource is shown in a BelongsTo
selection menu, that attribute will be displayed:
To customize the “title” attribute of a resource, you may define a title
property or title
method on the resource class:
Disable Ordering by Title
By default, associatable resources will be sorted by their title when listed in a select dropdown. Using the dontReorderAssociatables
method, you can disable this behavior so that the resources as sorted based on the ordering specified by the relatable query:
Filter Trashed Items
By default, the BelongsTo
field will allow users to select soft-deleted models; however, this can be disabled using the withoutTrashed
method:
BelongsToMany
The BelongsToMany
field corresponds to a belongsToMany
Eloquent relationship. For example, let’s assume a User
model belongsToMany
Role
models:
We may add the relationship to our User
Nova resource like so:
You may customize the resource class used by the relationship field by providing the second and third arguments to the make
method:
Once the field has been added to your resource, it will be displayed on the resource’s detail page.
Pivot Fields
If your belongsToMany
relationship interacts with additional “pivot” fields that are stored on the intermediate table of the many-to-many relationship, you may also attach those to your BelongsToMany
Nova relationship. Once these fields are attached to the relationship field, and the relationship has been defined on both of the related models / resources, they will be displayed on the related resource index.
For example, let’s assume our User
model belongsToMany
Role
models. On our role_user
intermediate table, let’s imagine we have a notes
field that contains some simple text notes about the relationship. We can attach this pivot field to the BelongsToMany
field using the fields
method:
Of course, it is likely we would also define this field on the inverse of the relationship. So, if we define the BelongsToMany
field on the User
resource, we would define its inverse on the Role
resource:
Don’t forget to define the pivot fields inside your Model’s relationship definition using the
withPivot
method:
https://laravel.com/docs/eloquent-relationships#retrieving-intermediate-table-columns
Since defining the field on both ends of the relationship can cause some code duplication, Nova allows you to pass an invokable object to the fields
method:
In this example, the RoleUserFields
class would be a simple, invokable class that returns the array of pivot fields:
Pivot Computed Fields
Laravel Nova also allows you to define computed fields within the field list of a belongsToMany
relationship field:
Pivot Actions
Typically, Nova actions operate on a resource. However, you may also attach actions to belongsToMany
fields so that they can operate on pivot / intermediate table records. To accomplish this, you may chain the actions
method onto your field’s definition:
Once the action has been attached to the field, you will be able to select the action and execute it from the relationship index on the parent resource’s detail page.
To learn more about Nova actions, check out the complete action documentation.
Title Attributes
When a BelongsToMany
field is shown on a resource creation / update page, a drop-down selection menu or search menu will display the “title” of the resource. For example, a Role
resource may use the name
attribute as its title. Then, when the resource is shown in a BelongsToMany
selection menu, that attribute will be displayed:
To customize the “title” attribute of a resource, you may define a title
property or title
method on the resource class:
Disabling Ordering by Title
By default, associatable resources will be sorted by their title when listed in a select dropdown. Using the dontReorderAttachables
method, you can disable this behavior so that the resources as sorted based on the ordering specified by the relatable query:
Allowing Duplicate Relations
By default, Laravel Nova ensures that “belongs to many” relationships are unique. However, if necessary, you may instruct Nova to allow duplicate relationship entries.
To get started, you should ensure that your pivot record’s id
column is available by using the withPivot
method when defining the relationship on your Eloquent model. In this example, let’s imagine that a User
may purchase a Book
one or more times:
Next, we can define the Nova relationship that allows duplicate relations using the allowDuplicateRelations
method:
MorphOne
The MorphOne
field corresponds to a morphOne
Eloquent relationship. For example, let’s assume a Post
has a one-to-one polymorphic relationship with the Image
model. We may add the relationship to our Post
Nova resource like so:
MorphOneOfMany
The MorphOne
relationship field can be transformed into a “morph one of many” Eloquent relationship using the ofMany
method. For example, let’s assume a Post
has a one-to-many polymorphic relationship with the Comment
model. We may add the relationship to our Post
Nova resource like so:
MorphMany
The MorphMany
field corresponds to a morphMany
Eloquent relationship. For example, let’s assume a Post
has a one-to-many polymorphic relationship with the Comment
model. We may add the relationship to our Post
Nova resource like so:
MorphTo
The MorphTo
field corresponds to a morphTo
Eloquent relationship. For example, let’s assume a Comment
model has a polymorphic relationship with both the Post
and Video
models. We may add the relationship to our Comment
Nova resource like so:
As you can see in the example above, the types
method is used to instruct the MorphTo
field what types of resources it may be associated with. Nova will use this information to populate the MorphTo
field’s type selection menu on the creation and update pages:
When a MorphTo
field is shown on a resource creation / update page, the title attributes of the available resources will automatically be displayed.
Nullable MorphTo
Relationships
If you would like your MorphTo
relationship to be nullable
, chain the nullable
method onto the field’s definition:
Peeking at MorphTo
Relationships
When hovering over a MorphTo
link when viewing the index or detail views, Nova will show a small card allowing you to “take a peek” at the linked relation:
Preventing Peeking at MorphTo
Relationships
Relationship peeking is enabled by default; however, you can prevent the user from peeking at the relation using the noPeeking
helper on your MorphTo
field:
You may also use the peekable
method to determine whether the user should be allowed to peek at the relation:
Setting Default Values on MorphTo
Relationships
When setting the default value for a MorphTo
field, in addition to setting the field’s initial value using the default
method, you also need to specify the class name of the resource to be used. You may accomplish this via the defaultResource
method:
MorphToMany
The MorphToMany
field corresponds to a morphToMany
Eloquent relationship. For example, let’s assume a Post
has a many-to-many polymorphic relationship with the Tag
model. We may add the relationship to our Post
Nova resource like so:
Pivot Fields
If your morphToMany
relationship interacts with additional “pivot” fields that are stored on the intermediate table of the many-to-many relationship, you may also attach those to your MorphToMany
Nova relationship. Once these fields are attached to the relationship field, they will be displayed on the related resource index.
For example, on our taggables
intermediate table, let’s imagine we have a notes
field that contains some simple text notes about the relationship. We can attach this pivot field to the MorphToMany
field using the fields
method:
Of course, it is likely we would also define this field on the inverse of the relationship. So, if we define the MorphToMany
field on the Post
resource, we would define it’s inverse on the Tag
resource:
Don’t forget to define the pivot fields inside your Model’s relationship definition using the
withPivot
method:
https://laravel.com/docs/eloquent-relationships#retrieving-intermediate-table-columns
Since defining the field on both ends of the relationship can cause some code duplication, Nova allows you to pass an invokable object to the fields
method:
In this example, the TaggableFields
class would be a simple, invokable class that returns the array of pivot fields:
Title Attributes
When a MorphToMany
field is shown on a resource creation / update page, a drop-down selection menu or search menu will display the “title” of the resource. For example, a Tag
resource may use the name
attribute as its title. Then, when the resource is shown in a MorphToMany
selection menu, that attribute will be displayed:
To customize the “title” attribute of a resource, you may define a title
property or title
method on the resource class:
Collapsable Relations
By default, the BelongsToMany
, HasMany
, and MorphToMany
relationship fields are shown on the resource detail page. However, this can quickly become cumbersome if a resource has many performance-intensive relationships which cause the page to be slow.
For this reason, Nova allows you to mark as relationship as collapsable
. When a relationship is collapsable, users may collapse some of the relations for a given resource and Nova will remember their preferences on subsequent page loads. Collapsed relationships are not retrieved from the database until the relationship is expanded in Nova’s user interface:
You may also indicate a relationship should always be collapsed by default via the collapsedByDefault
method:
Searchable Relations
By default, when the BelongsTo
, MorphTo
, BelongsToMany
and MorphToMany
relationship fields are shown on a resource creation / update page, a simple drop-down selection menu will be displayed. However, this can quickly become cumbersome if a resource model has many records. For example, imagine a drop-down selection menu populated with over 10,000 users!
Instead of displaying a drop-down selection menu, you may mark your relationships as searchable
. When a relationship is marked as searchable
, a beautiful search input control will be displayed instead:
To mark a relationship as searchable
, chain the searchable
method onto the field’s definition. If you would like to conditionally determine if a field should be searchable, you may pass a closure to the searchable
method:
You may also instruct the relation field to display the resource’s subtitle by invoking the withSubtitles
method when defining the field:
Relatable Query Filtering
If you would like to customize the relatable query, you may do so by invoking the relatableQueryUsing
method:
The relatableQueryUsing
method may also prove useful when you need to adjust the query based on the value of another field:
Limiting Relation Results
You can limit the number of results that are returned when searching the field by defining a relatableSearchResults
property on the class of the resource that you are searching for:
Creating Inline Relations
For convenience, When BelongsTo
or MorphTo
relationship fields are shown on a resource create or update page, you may create the related resource inline via a modal window without leaving the creation / update page:
To enable this functionality, invoke the showCreateRelationButton
method when defining the relationship field:
You may also pass a closure to the showCreateRelationButton
method to conditionally determine if inline resource creation should be enabled:
You may also create related many-to-many relationships from the “attach” and “update attached” pages. To enable this feature, invoke the showCreateRelationButton
when defining a BelongsToMany
or MorphToMany
relationship:
To hide the inline creation button, invoke the hideCreateRelationButton
method when defining the relationship field:
The inline relation creation process will respect any authorization policies you have defined.
Inline Creation Modal Size
You may adjust the size of the modal using the modalSize
method:
Inline relation creation only supports creating relations one level deep. This means you cannot trigger an additional inline creation modal inside an existing inline creation modal. Instead, you must select a resource that already exists.
Was this page helpful?