Since I am german and my day-by-day language is german, the following two pages will sound a bit "uncommon" to an native english speaker:

Please review the spelling on these 2 pages and provide suggestions in this issue. This would be very appreciated. I will correct the text on these pages asap.

Comments

Peter Majmesku created an issue. See original summary.

Peter Majmesku’s picture

Issue summary: View changes
ikit-claw’s picture

I made a few minor changes but this is how I would list it.

Acquia featured this module in their "Drupal 8 Module of the Week" series.

Why Permissions by Term module?

By default, Drupal allows you only to restrict access to Drupal nodes by coupling node content types to user roles and the creators of the content by their user account. The Permissions by Term module extends Drupal by functionality for restricting access to single nodes via taxonomy terms. Taxonomy terms are part of the Drupal core functionality. Taxonomy term permissions can be coupled to specific user accounts and/or user roles. Since Permissions by Term is using Node Access Records, every other core system will be restricted. Like core search, menus and views.

Additionally, the Permissions by Term module restricts access to taxonomy terms at the node edit form for content editors. Like the access restriction for nodes, also by single user accounts and user roles.

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.

Frontend Features:

Restricts users from accessing the nodes related to specific taxonomy terms by role and/or specific user accounts.
Restricts users from access to forbidden nodes in menus, search and views. The nodes will not be listed and are restricted from direct access.
Works with internationalization (i18n).

Administrator/Editor Backend Features:

Disallows users with administrative permissions by role and/or user account to select taxonomy terms on the node edit form, for which they don't have access. Please notice: This works for autocomplete term selection fields only.
Restricts access to nodes also on the backend side by user account and/or user role.
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 also with all DBM's which Drupal is supporting. E.g. SQLite.

more to follow...

ikit-claw’s picture

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 in the Group are created by the teacher and only visible to the students in the Group. Forums created in the Group are safe places to discuss the class as they are only accessible to the teacher and the students.
Multiple tier subscription content access. If you have several different collections of paid for content then you can charge for access to each Group you create. Buying access would grant you membership to one Group and be able to access its content.
Sub-editors on a magazine site. Collecting content together in a Group 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 Group for each conference. Members of a conference Group might be able to submit talk suggestions. Paying to attend the conference might grant them a higher level of access to the Group allowing them to see more content. Members of a group can also be given the ability to have their own profile within the Group which might collect details about them for the conference such as their meal preference.
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 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, ...)

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 ensure, that your Nodes are not accessible in the Drupal core search and menus if they are restricted by taxonomy terms.

ikit-claw’s picture

I will check the installation instructions for you tomorrow.

Peter Majmesku’s picture

@Daniel Pickering (ikit-claw): Thank you for your quick reaction! I have applied all your suggestions.

Please be so kind and mark your changes as bold text. That way it will be quicker to apply your changes.

Beside your changes, I was changing the project description a bit in the "Some example uses" section. It would be nice, if you could read it once.

ikit-claw’s picture

@Peter : I reviewed it offline and when I copied it into d.org it lost styling :(

I will take another look for you sometime this week.

Peter Majmesku’s picture

Status: Active » Closed (outdated)

I think the spelling is okay now. Thanks.