Module Description
This project is currently searching for co-maintainers. Please help, if you are currently working on a project which is based on Permissions by Term. 🫵🧐
Why Permissions by Term module? Per default, Drupal allows you only to restrict access to Drupal nodes by coupling node content types to user roles. The Permissions by Term module extends Drupal by functionality for restricting view access to single nodes via taxonomy terms. If you have installed the Permissions by Entity sub-module, any other content entity type, such as media entities, can be controlled in access restriction, too.
Please notice, that edit access is provided by hiding nodes from editors on the content admin views. There are no explicit create, edit or delete permissions provided.
Taxonomy term permissions can be coupled to specific user accounts and/or user roles. Taxonomy terms are part of the Drupal core functionality. Since Permissions by Term is using Node Access Records, every other core system will be restricted:
* search results
* Works well with Search API modules search result lists, since PbT version 8.x-2.0
* Drupal core search
* menu items
* views list items
* content from all content entity types (nodes, media)
Watch the hands-on user tutorial on YouTube
Access restriction features from Permissions by Term module Frontend Features
* Restricts users from access to forbidden nodes in menus, search and views. The nodes will not be listed and are restricted from node view.
* Restricted nodes in multiple languages. Drupal's Content Translation module is supported.
Administrator/Editor Backend Features
* Editors can use allowed taxonomy terms only, while editing nodes.
* Editors can edit nodes, which are related to allowed taxonomy terms.
* If single term restriction is enabled via configuration, users must have access to all related taxonomy terms, to access nodes. Otherwise access is granted, until they have access to only 1 related taxonomy term.
* Disallows users with administrative permissions by their role and/or user account to select taxonomy terms on the node edit form, for which they don't have access.
* Drupal 8 version only: To edit a certain node, users must have access to the related taxonomy term.
* Permissions by Term uses the object from the \Drupal\Core\Database\Connection namespace for database connections. Therefore it is tested to work not only with MySQL, but works also with all DBMs which Drupal is supporting. E.g. SQLite (good for quick local testing).
The Permissions by Term module provides features for the front- and backend. No programming skills required. This module can be handled by Drupal site builders via the user interface in the web browser.
Easy install: You do not need Composer to install Permissions by Term.
Some example uses:
* Classes on a school website. With a teacher as the administrator, students as the members and the content as the learning material. Articles related to the taxonomy term are created by the teacher and only visible to the students related to the taxonomy term. Forums created via taxonomy terms are safe places to discuss the class as they are only accessible to the teacher and the students. You can treat a taxonomy term to nodes relation as a content group.
* Multiple tier subscription content access. If you have several different collections of paid for content then you can charge for access to each taxonomy term you create. Buying access would grant you membership to one taxonomy term and be able to access its content.
* Sub-editors on a magazine site. Collecting content together in a taxonomy term allows you to manage that content as a sub site and assign its own administrator. This is useful where you might need someone to produce lots of different types of content but only want them to be able to add it to a specific area of the website.
* Sub-communities within a membership organisation. The topics a membership organisation may cover can be very broad and individual members may only be interested in seeing content from a sub-selection of the areas it covers. The sub-community may have their own executive members who can add blog posts or approve new members to their sub-community.
* Conference management. An organisation which manages conferences might have a taxonomy term for each conference. Members of a conference taxonomy term might be able to submit talk suggestions. Paying to attend the conference might grant them a higher level of access to the taxonomy term allowing them to see more content. Users with granted access to a taxonomy term are members and can also be given the ability to have their own profile within the taxonomy term which might collect details about them for the conference such as their meal preference. You can list the members by selecting the 2 database tables (1 for users and 1 for roles) from Permissions by Term module or use the services from Permissions by Term as a programming API. Views can also be an option, since Permissions by Term is filtering out all content from views, for which users do not have access. This happens without any configuration. All views are handled by Permissions by Term automatically.
What about Organic Groups and the Group module? The Permissions by Term module is designed to be a lightweight and easily understandable alternative to Organic Groups and Group. Permissions by Term does not introduce its own entities. It relies on the entities, which are shipped traditionally with Drupal core: taxonomy terms and nodes.
Organic Groups allows content itself to be grouped, which isn't always what people want. It relies on an entity reference field to keep track of the ties between a group (node, term, ...) and its content (node, term, user, ...). The development of this project also does not happen on Drupal.org, but on GitHub, what might matter for Drupal community members.
Group introduces a lot of its own entity types to group the content. It adds an own sub-system for content grouping to Drupal, which is already possible by nodes and taxonomy terms.
Permissions by Term also ensures, that your nodes are not accessible in the Drupal core search, menus and views and any other properly implemented content presentation layer, if the nodes are restricted by taxonomy terms. Restriction does happen in the overall Drupal system and not only in any subsystem like via the Group and Organic Groups projects.
An alternative to PbT: Taxonomy Access Control Lite The Taxonomy Access Control Lite module project does quite the same things as PbT does. Additionally it restricts the edit/delete permissions on Drupal nodes. You might take a look on this module also for usage within your project.
Please notice, that this project was developed without any automated tests (be aware of regressions in your software) and the configuration user interface is more complicated. To configure this module you have several forms on different URLs. While PbT bundles the permission configuration on the taxonomy term edit page. Furthermore Taxonomy Access Control Lite works with "schemes" for each taxonomy vocabulary, what eventually makes the maintenance of your project more complicated, than you want it to be.
Drupal 7 The Drupal 7 version is not supported anymore. You can download the last release via this url: https://www.drupal.org/project/permissions_by_term/releases/7.x-1.31. You may check the Taxonomy Access Control Lite module project.
Documentation Visit PbT's documentation page on Drupal.org to learn how to use it.
Modules which extend PbTs functionality
* Permissions by Term Redirect: Redirects users to the user login form, if PbT has denied access for an node. After a successful login, the user is redirected to the desired node view.
* Webform Permissions By Term
* Permissions by Entity (now integrated into Permissions by Term)
Further resources on blogs
* Managing Drupal content permissions with the Permissions by Term module
* Access control modules for Drupal 8
* The Permissions by Term module
Why Permissions by Term module? Per default, Drupal allows you only to restrict access to Drupal nodes by coupling node content types to user roles. The Permissions by Term module extends Drupal by functionality for restricting view access to single nodes via taxonomy terms. If you have installed the Permissions by Entity sub-module, any other content entity type, such as media entities, can be controlled in access restriction, too.
Please notice, that edit access is provided by hiding nodes from editors on the content admin views. There are no explicit create, edit or delete permissions provided.
Taxonomy term permissions can be coupled to specific user accounts and/or user roles. Taxonomy terms are part of the Drupal core functionality. Since Permissions by Term is using Node Access Records, every other core system will be restricted:
* search results
* Works well with Search API modules search result lists, since PbT version 8.x-2.0
* Drupal core search
* menu items
* views list items
* content from all content entity types (nodes, media)
Watch the hands-on user tutorial on YouTube
Access restriction features from Permissions by Term module Frontend Features
* Restricts users from access to forbidden nodes in menus, search and views. The nodes will not be listed and are restricted from node view.
* Restricted nodes in multiple languages. Drupal's Content Translation module is supported.
Administrator/Editor Backend Features
* Editors can use allowed taxonomy terms only, while editing nodes.
* Editors can edit nodes, which are related to allowed taxonomy terms.
* If single term restriction is enabled via configuration, users must have access to all related taxonomy terms, to access nodes. Otherwise access is granted, until they have access to only 1 related taxonomy term.
* Disallows users with administrative permissions by their role and/or user account to select taxonomy terms on the node edit form, for which they don't have access.
* Drupal 8 version only: To edit a certain node, users must have access to the related taxonomy term.
* Permissions by Term uses the object from the \Drupal\Core\Database\Connection namespace for database connections. Therefore it is tested to work not only with MySQL, but works also with all DBMs which Drupal is supporting. E.g. SQLite (good for quick local testing).
The Permissions by Term module provides features for the front- and backend. No programming skills required. This module can be handled by Drupal site builders via the user interface in the web browser.
Easy install: You do not need Composer to install Permissions by Term.
Some example uses:
* Classes on a school website. With a teacher as the administrator, students as the members and the content as the learning material. Articles related to the taxonomy term are created by the teacher and only visible to the students related to the taxonomy term. Forums created via taxonomy terms are safe places to discuss the class as they are only accessible to the teacher and the students. You can treat a taxonomy term to nodes relation as a content group.
* Multiple tier subscription content access. If you have several different collections of paid for content then you can charge for access to each taxonomy term you create. Buying access would grant you membership to one taxonomy term and be able to access its content.
* Sub-editors on a magazine site. Collecting content together in a taxonomy term allows you to manage that content as a sub site and assign its own administrator. This is useful where you might need someone to produce lots of different types of content but only want them to be able to add it to a specific area of the website.
* Sub-communities within a membership organisation. The topics a membership organisation may cover can be very broad and individual members may only be interested in seeing content from a sub-selection of the areas it covers. The sub-community may have their own executive members who can add blog posts or approve new members to their sub-community.
* Conference management. An organisation which manages conferences might have a taxonomy term for each conference. Members of a conference taxonomy term might be able to submit talk suggestions. Paying to attend the conference might grant them a higher level of access to the taxonomy term allowing them to see more content. Users with granted access to a taxonomy term are members and can also be given the ability to have their own profile within the taxonomy term which might collect details about them for the conference such as their meal preference. You can list the members by selecting the 2 database tables (1 for users and 1 for roles) from Permissions by Term module or use the services from Permissions by Term as a programming API. Views can also be an option, since Permissions by Term is filtering out all content from views, for which users do not have access. This happens without any configuration. All views are handled by Permissions by Term automatically.
What about Organic Groups and the Group module? The Permissions by Term module is designed to be a lightweight and easily understandable alternative to Organic Groups and Group. Permissions by Term does not introduce its own entities. It relies on the entities, which are shipped traditionally with Drupal core: taxonomy terms and nodes.
Organic Groups allows content itself to be grouped, which isn't always what people want. It relies on an entity reference field to keep track of the ties between a group (node, term, ...) and its content (node, term, user, ...). The development of this project also does not happen on Drupal.org, but on GitHub, what might matter for Drupal community members.
Group introduces a lot of its own entity types to group the content. It adds an own sub-system for content grouping to Drupal, which is already possible by nodes and taxonomy terms.
Permissions by Term also ensures, that your nodes are not accessible in the Drupal core search, menus and views and any other properly implemented content presentation layer, if the nodes are restricted by taxonomy terms. Restriction does happen in the overall Drupal system and not only in any subsystem like via the Group and Organic Groups projects.
An alternative to PbT: Taxonomy Access Control Lite The Taxonomy Access Control Lite module project does quite the same things as PbT does. Additionally it restricts the edit/delete permissions on Drupal nodes. You might take a look on this module also for usage within your project.
Please notice, that this project was developed without any automated tests (be aware of regressions in your software) and the configuration user interface is more complicated. To configure this module you have several forms on different URLs. While PbT bundles the permission configuration on the taxonomy term edit page. Furthermore Taxonomy Access Control Lite works with "schemes" for each taxonomy vocabulary, what eventually makes the maintenance of your project more complicated, than you want it to be.
Drupal 7 The Drupal 7 version is not supported anymore. You can download the last release via this url: https://www.drupal.org/project/permissions_by_term/releases/7.x-1.31. You may check the Taxonomy Access Control Lite module project.
Documentation Visit PbT's documentation page on Drupal.org to learn how to use it.
Modules which extend PbTs functionality
* Permissions by Term Redirect: Redirects users to the user login form, if PbT has denied access for an node. After a successful login, the user is redirected to the desired node view.
* Webform Permissions By Term
* Permissions by Entity (now integrated into Permissions by Term)
Further resources on blogs
* Managing Drupal content permissions with the Permissions by Term module
* Access control modules for Drupal 8
* The Permissions by Term module
Module Link
Project Usage
4748
Security Covered
Covered By Security Advisory
Version Available
Production
Module Summary
Permissions by Term module provides functionality for restricting view access to single nodes via taxonomy terms, extending Drupal's default access control features.
Data Name
permissions_by_term
OPENAI CHATBOT
OPENAI CHATBOT
