Drupal has long had a variety of access control modules, to make it so you can easily control who can view or edit particular pages. There are actually several different layers of APIs to control this in Drupal core -- the modules generally provide a user interface to let you control access by content type, by tagging content with particular terms, through their position on a menu, or through a group. The Field Permissions module lets you control access to particular fields on an entity.
There are many scenarios where these modules still make sense to use. In particular, most of them sit on top of the "entity access" system, which not only gates access to particular nodes, but also alters database queries in Views and other modules to make sure content a user should not access gets completely excluded from views.
The Events, Conditions, and Actions (ECA) module provides a simpler approach to simply forbid (or grant) access to any particular node you want, for any particular reason. It does not rewrite queries to keep views from loading blocked content -- although it can block viewing it even so -- the difference here is that if you use the entity access API on a view that would load the first 10 items, you would always get those 10 items, but with ECA it might load 10 items but then not show 3 of them because you don't have access -- so you would only see 7. But on the flip side, if you're using ECA in a bunch of places, this becomes an extremely easy way to control access.
Drupal 10.3 added a new Access Policy API, which allows you to define policies that align with a cache. ECA does not yet support this API, but it seems like a natural fit.
With current ECA Access rules, you can grant or deny access to particular content based on any rules you can think of, but there's one problem -- caching. For example, in an earlier post we showed how ECA can change the display of an event after it has happened. When an event date is reached, the page display for it does remain cached. For that scenario, we did not consider this to be a problem, because the event content is edited fairly promptly after the event to attach a video, and it may get other edits around pictures, summaries, etc -- any of these changes invalidate the cache and so the display mode changes soon enough after the event that nobody cares.
If this were important, that's what the Access Policy API is for -- defining new cache contexts that are associated with permissions. This allows having office hours defined, where users have access to content only during particular hours, and because it's defined in the cache context, as soon as the context (or ECA rules) match, the behavior changes.
That's just a hint at what's to come -- for now, if you need a quick way to make a field editable by admins only, or a way to limit access to particular content for particular users, check out ECA, it might just do the trick!
Add new comment