My first blog post detailed some of my thoughts related to Data Security in content management platforms. Recently I have been working on improving the access control layers in Drupal.
Background
I work full time as a web developer at Rutgers University. The majority of the projects I maintain are Drupal websites. Beyond them, we have a handful of custom tools written in both PHP and Python that are used across the university. One of my recent projects was overhauling a knowledge base application originally built with Drupal 7. The tool had plenty of requirements, ranging from the need for complex access control to supported display concepts which had been maintained through a few generations and different platforms. The version I took over when I started the job had been built in Drupal 7, by a part-time supervisor for the support group. It did the job, but with the limitations the original developer had, the tool used big ticket contributed modules. This site became a flagship case for "just cause it works, doesn't mean it’s right."
My goal
I had two goals during the rebuild Make it designed well and make it fast. Speed in Drupal is a huge topic, so for now I am just going to focus on design.
The old portal leveraged Taxonomy Access Control and a lot of magic to provide the expected interfaces for the site. Taxonomy Access is a good module; it leverages content tags, like categories, to access control content. It's flexible and allows the developer to leverage it as they need to. It can be used for simply editor access or to restrict content visibility.
The portal was built on magic. Views were leveraged throughout the tool, which usually is a good thing. However, in this case the views pushed the limits of its design. In many cases, unintuitive functions were built with views in order to work around feature gaps in the module list. One particular interface grouped content by title; which by itself sounds logical, but to a user, getting content to exist in that location was not obvious. The group had significant internal training though, so the staff knew how to use the less intuitive interfaces.
A Clean Slate and No Chalk
When building the new version of the site I choose to start with Drupal 8. There are a lot of great changes to the developer side of Drupal 8. Using a solid framework, object oriented design, and other modern mechanics, Drupal 8 provides a good developer experience. There is a learning curve and still a great lack of documentation in some areas, but overall everything you need is there. Moving to Drupal 8 gave me a clean slate.
Even now, a few years after release, Drupal 8 module support is behind. There are a large number Drupal 7 modules, but not all of them have been ported to Drupal 8. This means for someone not willing to write code, they are boxed into having only a few options. Luckily, I am not one of those people and was not afraid to get into Drupal module development. It even resulted in me contributing 10 of my own projects to Drupal.org.
For access control, there were only a few options. First and foremost, TAC Lite the successor to Taxonomy Access was available. Beyond that there were a few modules built around a early version of Organic Groups but not too many other modules to solve some of the complicated use cases I needed.
The Rework
I started from the ground up. The support group at Rutgers that used the tool has a handful of different units that share staff and resources, but also require unique information for the whole array of topics and content on the site. This left me with the challenge of providing an intuitive UI for the staff updating the content as well as making it easy to find and read the content. With the intermingled siloing access control needed to stem not just from a role, but different horizontal groups across the org, creating infinite grouping combinations for the almost 50 different positions.
Ultimately I decided that most of the site's content followed one design premise. There typically was one large and widely available content blob, usually bundled with a handful of targeted content linked to it. Targeted content typically was for a specific position or set of them. I needed to structure docs around this concept. They gave me general skeleton, and implementation came after.
Paragraphs over Field Collections
In the Drupal Community, there is often a large duplication of effort. Multiple modules that cover the same use cases with slightly varying features and implementation. This is the case with two modules. Field Collections and Paragraphs is a prime case for this. Field Collections is now defunct, and passed by in favor of Paragraphs. But the two modules do provide the same feature. The ability to add customized field groupings to a Drupal Entity. Field Collections provided a unique grouping per field instance, while paragraphs gave the user reusable types.
I started the project with a basic content type which had a body and access control. I then added to it a Field Collection to contain additional position targeted content. Following the outlook that Field collection would be no longer developed in favor of Paragraph I eventually made that move. In the long run I am glad I did. I probably will touch more on that in a future post about the Drupal Search API and Apache Solr
Access Control
This post was going to be about a module I recently published on Drupal.org called Advanced Access. I started writing it and need to give background. I will be making a dedicated post about Advanced Access soon, but wanted to be able to reference this project without going into too much detail. But this is the backstory about where Advanced Access was born.
The knowledge base leveraged a custom module I wrote called Role Access Control (RAC). The site I took over used Taxonomy Access to grant viewing and editing of content. The vocabulary leveraged by TAC mimicked almost perfectly the user role list configured on the site. It was tedious for the admins to maintain, thankfully changes did not happen often. RAC was born out of simplifying access maintenance. By leveraging a Role reference field in place of the Taxonomy terms, I could produce the same access structure without jumping through the hoops and complexity.
Nodes and Paragraphs
There were two types of things that RAC needed to control access to. The Content nodes and the targeted content, built with Paragraphs. However, there was no out of the box way to access control paragraphs. Then Paragraphs Access 1.x was born, to mimic the Node Access API provided by Drupal Core and allow the same concepts to be used for its modules and plugins. Then RAC 1.x provided an integration to access control Paragraphs. Clear for takeoff!
At the time, that basically wrapped up the site's access system. Some polish was put on the function with modules such as Entity Reference Automation to simplify the work a user needed to do in order to distribute content and the site was deployed. I hopefully will feature ER Auto and the other modules at a future point.
Then It Got Tricky
The site leveraged Apache Solr for search, and did some fancy things with it. The original design of those flashy features caused problems for the search function and required a rework. The rework, combined with the extension of the Paragraphs usage on the site, made a mess out the access control layer and ushered the groundbreaking for Advanced Access.
Advanced Access Introduction
Just a few word on Advanced Access for now, but more to come. Advanced Access took a majority of the heavy lifting being done by my Paragraphs Access module, as well as by is predecessor Field Collections Access, and the Role Access Control modules, and wrapped them up into a pretty plugin based implementation and a bridge for those plugins to be supported by Node Access. It also lays the groundwork to simplify future access control plugins and give developers less to worry about when iterating with complex environments.
Conclusion
Good software is built when people work together. I hope the modules that I have contributed to Drupal.org, will help other developers build better and more powerful sites.
If there are any questions about the modules features here, please post in their issues queues or reach out to me.