Submitted by Chris McIntosh on December 6, 2019

Drupal 8 Views comes with a couple of different access plugins when you first install it and for the most part, they will probably cover most situations you will need them for. These standard ones include access based on Role or Permission.  These can be found under the Page Settings section on views next to Access.  

views access settings

However, sometimes these are just not smart enough to handle the job.  If you have created some of your own access rules that you need, but can't just create a simple role or permission then this is where it would be the time to create your own Custom Views Access Plugin. 

For this use case we are going to create the view called the Temple of Doom, inspired by Indiana Jones.  With this view we want to have it so that only a user with last name "Jones" can access the name is being stored in the user's customer profile for Commerce.

Determining if someone has the correct last name in their profile requires a couple of steps, that we wont dive into too much here, but lets get into creating the Access Handler class we will leverage to make this possible.

In addition to the two functions holding our logic, we also have an additional access function that takes both the AccountInterface variable and a Route variable.  We will talk a bit more about that further on in the tutorial, so just keep it in mind.

Creating your Views Access Plugin

Most of the access plugins created tend to extend from the Drupal\views\Plugin\views\access\AccessPluginBase class, and will need to include at least three methods for it to work: alterRouteDefinition(), access(), and summaryTitle().

Because it is a plugin you will need to make sure that you have a class annotation to describe the metadata to drupal.  For our TempleOfDoomAccess plugin it will look like this:

As expected the access() method implementation will return a boolean value letting views and Drupal know if the active user can access it.  Additionally the summaryTitle() method will return the label used in the Views UI settings screen, you should try to make it descriptive and try to make sure you are not using a similar label to something other contrib modules may use.

The final remaining function in this plugin is the alterRouteDefinition() method.  This method helps with how Drupal 8 manages routes. When Drupal builds it's route table this function will be called as well.  

In some cases you may also want to hide any menu items that are linking to the view, in fact in most cases this will be true.  For these cases you will want to make sure that your alterRouteDefinition method sets the requirement. This is similar to how you would set a custom access handler in your routing yaml file.

Taking it a step further with User-defined settings

This all should work good, but what if there is a case where you also need to allow the administrator to configure things, maybe add in extras to the list that are allowed in.  This is where user-defined options come into play.

All you need to do is add a couple of new methods defineOptions() and buildOptionsForm() the first will allow you to define the options that you will be using in your plugin. The second is what it sounds like. It builds a form array and returns it for the user to interact with.

Finishing things out

As you have seen above with only a few new classes and a handful of methods you can exert a lot of control over how and who accesses your views.  This is a great tool in the box of developers who are working with complex business cases.