Defining Actions
Defining actions in Nova
Nova actions allow you to perform custom tasks on one or more Eloquent models. For example, you might write an action that sends an email to a user containing account data they have requested. Or, you might write an action to transfer a group of records to another user.
Once an action has been attached to a resource definition, you may initiate it from the resource’s index or detail pages:
If an action is enabled for display on the resource’s table row, you may also initiate the action from the resource’s action dropdown menu via the resource index page. These actions are referred to as “Inline Actions”:
Overview
Nova actions may be generated using the nova:action
Artisan command. By default, all actions are placed in the app/Nova/Actions
directory:
You may generate a destructive action by passing the --destructive
option:
To learn how to define Nova actions, let’s look at an example. In this example, we’ll define an action that sends an email message to a user or group of users:
The most important method of an action is the handle
method. The handle
method receives the values for any fields attached to the action, as well as a collection of selected models. The handle
method always receives a Collection
of models, even if the action is only being performed against a single model.
Within the handle
method, you may perform whatever tasks are necessary to complete the action. You are free to update database records, send emails, call other services, etc. The sky is the limit!
Action Titles
Typically, Nova utilizes the action’s class name to determine the displayable name of the action that should be shown in the action selection menu. If you would like to change the displayable name of the action, you may define a name
property on the action class:
Destructive Actions
You may designate an action as destructive or dangerous by defining an action class that extends Laravel\Nova\Actions\DestructiveAction
. This will change the color of the action’s confirm button to red:
When a destructive action is added to a resource that has an associated authorization policy, the policy’s delete
method must return true
in order for the action to run.
Action Callbacks
The Action::then
method should not be utilized if your action is queued. To achieve similar functionality when using queued actions, you should leverage Nova’s action batching callbacks.
When running an action against multiple resources, you may wish to execute some code after the action has completed executing against all of the resources. For example, you may wish to generate a report detailing all of the changes for the selected resources. To accomplish this, you may invoke the then
method when registering your action.
The then
methods accepts a closure which will be invoked when the action has finished executing against all of the selected resources. The closure will receive a flattened Laravel collection containing the values that were returned by the action.
For example, note that the following action’s handle
method returns the $models
it receives:
When registering this action on a resource, we may use the then
callback to access the returned models and interact with them after the action has finished executing:
Action Fields
Sometimes you may wish to gather additional information from the user before dispatching an action. For this reason, Nova allows you to attach most of Nova’s supported fields directly to an action. When the action is initiated, Nova will prompt the user to provide input for the fields:
To add a field to an action, add the field to the array of fields returned by the action’s fields
method:
Finally, within your action’s handle
method, you may access your fields using dynamic accessors on the provided ActionFields
instance:
Action Fields Default Values
You may use the default
method to set the default value for an action field:
Action Responses
Typically, when an action is executed, a generic “success” messages is displayed in the Nova UI. However, you are free to customize this response using a variety of methods available via the ActionResponse
class. To display a custom “success” message, you may invoke the ActionResponse::message
method from your handle
method:
To return a red, “danger” message, you may invoke the ActionResponse::danger
method:
Redirect Responses
To redirect the user to an entirely new location after the action is executed, you may use the ActionResponse::redirect
method:
To redirect the user to another location within Nova, you may use the ActionResponse::visit
method:
To redirect the user to a new location in a new browser tab, you may use the ActionResponse::openInNewTab
method:
Download Responses
To initiate a file download after the action is executed, you may use the ActionResponse::download
method. The download
method accepts the desired name of the file as its first argument, and the URL of the file to be downloaded as its second argument:
Custom Modal Responses
In addition to the customization options provided before and during an action’s execution, Nova also supports the ability to present a custom modal response to the user. This allows you to provide additional context or follow-up actions to the user, customized to your use-case.
For example, let’s imagine you have defined an action named GenerateApiToken
, which creates unique tokens for use with a REST API. Using a custom action response modal, you could show the user running the action a modal allowing them to copy the newly-generated API token to their clipboard.
Using the nova:asset
Artisan command, you may generate a custom asset and register the custom modal with Nova’s Vue instance:
Next, you may use the modal
method within your action’s handle
method, which will instruct Nova to show the modal after running the action, passing the Vue component’s name and any additional data you specify to the component. The data will be made available to the custom modal’s Vue component as props:
Queued Actions
Occasionally, you may have actions that take a while to finish running. For this reason, Nova makes it a cinch to queue your actions. To instruct Nova to queue an action instead of running it synchronously, mark the action with the ShouldQueue
interface:
You may quickly create a queued Nova action by providing the --queued
option when executing the nova:action
Artisan command:
When using queued actions, don’t forget to configure and start queue workers for your application. Otherwise, your actions won’t be processed.
At this time, Nova does not support attaching File
fields to a queued action. If you need to attach a File
field to an action, the action must be run synchronously.
Customizing the Connection and Queue
You may customize the queue connection and queue name that the action is queued on by setting the $connection
and $queue
properties within the action’s constructor:
Job Batching
You may also instruct Nova to queue actions as a batch by marking the action with the Laravel\Nova\Contracts\BatchableAction
interface. In addition, the action should use the Illuminate\Bus\Batchable
trait.
When an action is batchable, you should define a withBatch
method that will be responsible for configuring the action’s batch callbacks. This allows you to define code that should run after an entire batch of actions finishes executing against multiple selected resources. In fact, you can even access the model IDs for all of the resources that were selected when the batched action was executed:
Action Log
It is often useful to view a log of the actions that have been run against a particular resource. Additionally, when queueing actions, it’s often important to know when the queued actions have actually finished executing. Thankfully, Nova makes it a breeze to add an action log to a resource by attaching the Laravel\Nova\Actions\Actionable
trait to the resource’s corresponding Eloquent model.
For example, we may attach the Laravel\Nova\Actions\Actionable
trait to the User
Eloquent model:
Once the trait has been attached to the model, Nova will automatically begin displaying an action log at the bottom of the resource’s detail page:
Disabling the Action Log
If you do not want to record an action in the action log, you may disable this behavior by adding a withoutActionEvents
property on your action class:
Or, using the withoutActionEvents
method, you may disable the action log for an action when the action is attached to a resource. Disabling the action log is often particularly helpful when an action is often executed against thousands of resources at once, since it allows you to avoid thousands of slow, sequential action log database inserts:
Queued Action Statuses
While a queued action is running, you may update the action’s “status” for any of the models that were passed to the action via its model collection. For example, you may use the action’s markAsFinished
method to indicate that the action has completed processing a particular model:
Or, if you would like to indicate that an action has “failed” for a given model, you may use the markAsFailed
method:
Action Modal Customization
By default, actions will ask the user for confirmation before running. You can customize the confirmation message, confirm button, and cancel button to give the user more context before running the action. This is done by calling the confirmText
, confirmButtonText
, and cancelButtonText
methods when defining the action: