Search by

faithcatholic / custom_node_access

nketchummjones

Adds option for page access by role

Package info

github.com/FaithCatholic/custom_node_access

Type:drupal-module

pkg:composer/faithcatholic/custom_node_access

Statistics

Installs: 1 491

Dependents: 0

Suggesters: 0

Stars: 0

Open Issues: 0

v4.0.0 2026-09-10 00:55 UTC

README

Custom Node Access lets an editor restrict who can view a single node by picking user roles on the content form. The selection is stored in a field the module provides, and turned into node access grants through core's node grants system, so a restricted node disappears from listings and views for everyone outside the selected roles, not just from its own page. A node with no roles selected stays unrestricted. The module also grants authenticated users view access to nodes while /system/files is being served, so private files embedded in a restricted node still load.

Requirements

Drupal 10.3 or later, or Drupal 11. Core's Node and Field UI modules, nothing from contrib.

The module does nothing on its own. It expects a field to exist on every content type you want to control:

  • Field type Access (access_type), provided by this module.
  • Machine name field_access, exactly. The name is hardcoded in the grants hook and in the widget's #states selector, so a field with any other name is ignored without an error.
  • Cardinality 1. Only the first value is read.

Grant the Edit custom node access permission to any role that should see the setting on the content form.

Installation

Enable at /admin/modules, or drush en custom_node_access.

Then add the field_access field described above to each content type you want to restrict. Without it the module is inert, which is the usual reason it looks like it does not work on a fresh install.

Usage

  • Go to Manage fields on a content type, add a field of type Access, and set the machine name to field_access. Keep the default settings.
  • Edit a node. Users with the Edit custom node access permission get a User role access section in the sidebar of the content form.
  • Select one or more roles to limit who can view that node. Select none to leave it open to everyone. Roles flagged as admin roles are not offered, since they bypass node access anyway.
  • Grants are written when the node is saved. If grants look stale, for example after adding the field to an existing content type, rebuild them at /admin/reports/status or with drush php:eval 'node_access_rebuild();'.
  • The field formatter renders the selected roles as a comma separated list of role labels, so you can show the restriction on the node if you want to.

Development

The repository is the module itself. DDEV builds a Drupal site around it: web/ and vendor/ are ignored by git, and the module is symlinked into web/modules/custom/custom_node_access.

ddev start runs the bootstrap in .ddev/post-start.sh: it fetches core and dependencies with ddev poser, installs the site if the database is empty, symlinks the project, enables Devel and this module, and prints a drush uli login link. The account is admin with password 1.

Checks:

  • ddev phpcs and ddev phpcbf for Drupal coding standards.
  • ddev phpstan --level=6 -c ../../../../phpstan.neon for static analysis. Pass the config explicitly. Plain ddev phpstan symlinks the config into the module directory with a relative path that does not resolve, so it silently runs at level 0 with no configuration.

Add-ons in use: ddev-drupal-contrib, ddev-drupal-contrib-extras, ddev-drupal and ddev-pimp-my-shell.

Notes

  • Grant IDs are derived from the role machine name: underscores are stripped, the result is converted from base 36 to base 10, and the first five digits are used. Two roles can therefore end up with the same grant ID, and content_editor and contenteditor always do. Renaming a role changes its grant ID, so rebuild permissions after a rename.
  • The /system/files rule grants view access to any node for any authenticated user while that path is being served. It exists so private files embedded in restricted nodes keep loading. Keep it in mind if you rely on node access for anything else served from that path.
  • The three field plugins still use annotations rather than PHP attributes. Annotations are deprecated and will be removed in Drupal 12.
  • The procedural hook functions in custom_node_access.module are thin delegates kept for Drupal 10, which has no attribute based hooks. They can be deleted once the minimum supported version is Drupal 11.1.
  • The Drupal 10 path is untested. The delegates and the autowired service definition are there for it, but everything in this repository has only been run against Drupal 11.4.
  • CUSTOM_NODE_ACCESS_GRANT_ALL is defined but never used.