Drupal 8 Module of the Week: Permissions by Term

What does the Permissions by Term Module do?

“Permissions by Term (PbT) lets you easily build access-restricted content areas on your websites. With it, you let certain users or groups of users see (or not see) specific pieces of content,” explains Peter. It restricts user access to specified Drupal nodes based on taxonomy terms. These permissions can be associated with individual user accounts and/or user roles. While Drupal has generally good, granular access permissions for the creation and editing of content, its fundamental assumption is also, more or less, that site visitors should all be able to see all published content on a site. A number of use cases come to mind where you’d want to be able to restrict access to some content at a more granular level than authenticated/anonymous (aka “logged-in/not-logged-in”):

• A club or service site with premium- or member-only content.
• School websites with content intended for teachers only and content aimed at individual classes within the school.
• Company intranets with sensitive or proprietary content alongside non-restricted content.

Why is this important?

Permissions by Term is a lightweight alternative to Organic Groups or Group in that it only provides access control over content, but not things like subscribing to groups, and everything else that the two “group” alternatives offer. Furthermore, Permissions by Term restricts user access to specified Drupal nodes based on taxonomy terms–a core part of Drupal’s functionality. PbT lets you restrict content access while relying on very little contributed code. Group and Organic Groups come with their own entity types and additional overhead. PbT simply extends your existing content types by a single field, “It provides functionality to restrict access by taxonomy terms. This works out-of-the-box for Drupal site-builders and non-coders. Developers can build custom functionality on top of the Permissions by Term module.”

Peter explains his dilemma at the time he chose to create Permissions by Term, “I looked around for a content access solution that met my needs or one that I could adapt. That didn’t work out for me–hence, my module. Now that my module is running on more than 100 sites, what I really want is for this to be a solid, supported, community-proven code-base. I’d be very happy to accept more patches, create new sub-modules, or whathaveyou. With this project, we can share and build on our experiences together. The point is, we don’t need to reinvent stuff. We can work together as a community and build our websites more efficiently.”

“Please don’t hesitate to install the module, check it out! If you have feedback, want to share something, file an issue, work on something together, create an issue in the project’s issue queue or contact me and I’ll be very happy to answer you!”

Much like adding images and galleries, access-control is an area in Drupal that has seen a number of approaches and solutions over the years. For a blast from the past, here’s an older Drupal.org post trying to get an overview of this tricky landscape: Controlling Access to Content Overview. You’ll see it’s full of abandoned projects, varied use cases, and some extremely niche solutions.