Snipe-IT Asset Management Installation Documentation

Welcome to the Snipe-IT documentation hub. You'll find comprehensive guides and documentation to help you install Snipe-IT as quickly as possible, as well as support if you get stuck. Let's jump right in!

Get Started    

User Permissions

Snipe-IT uses Policies to determine whether a user should be able to view, edit, delete, etc a resource.

The policies are location in app/Policies, and extend from app/Policies/SnipePermissionsPolicy.php, which does the more complex work of determining whether or not a user should be able to perform a specific action.

To utilize these policies in a controller method, you would use something like:

public function audit() {

    $this->authorize('audit', Asset::class);
    // Do authorized stuff here


If the authorization fails, it will return a forbidden error.

When editing blades, you can use the @can and @cannot short syntax.

For example, to determine whether or not to display the option to a logged in user, you would write:

@can('view', \App\Models\Asset::class)
    <a href="{{ route('assets.index') }}">

Creating New Permissions

If you're creating a new model or permission set, there are a few steps you have to take before all of these pieces work together.

SnipePermissionsPolicy provides methods for handling the granular permissions used throughout Snipe-IT.

Each "area" of a permission (which is usually a model, like Assets, Departments, etc), has a setting in config/permissions.php like view/create/edit/delete (and sometimes some extra stuff like checkout/checkin, etc.)

A Policy should exist for each of these models, however if they only use the standard view/create/edit/delete , the policy can be pretty simple, for example with just one method setting the column name. Let's say we're creating a new permission mask for a new model named Florb.

We'll need to create a new Policy in app/Policies, named FlorbPolicy:


namespace App\Policies;

use App\Policies\SnipePermissionsPolicy;

class FlorbPolicy extends SnipePermissionsPolicy
    protected function columnName()
        return 'florbs';

We'll also need to tell the AuthServiceProvider to take that new policy into consideration. In app/Providers/AuthServiceProvider.php, we'll need to make sure we add use App\Models\Florb and App\Policies\FlorbPolicy - and then add the new policy into the protected $policies array:


namespace App\Providers;

use App\Models\Florb;
use App\Policies\FlorbPolicy;

     * The policy mappings for the application.
     * See SnipePermissionsPolicy for additional information.
     * @var array
    protected $policies = [
        Florb::class => FlorbPolicy::class,


Permissions Considerations

While handling permissions is usually pretty straightforward, there are some areas where it can get a little complicated, not from a programming perspective, but from a logic perspective. For example, if a user can checkout assets, they inherently have to be able to view a list of users, locations and other assets, so that they can select them in the checkout interface.

Be sure to think though the implications of any permission policies you implement.

Updated about a year ago

User Permissions

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.