Friday marked the end of our very first two-week Scrum sprint. As a result, we have the first iteration of our user registration form, as well as some adminstrative tools to manage users, which we will demo for our staff Stakeholders on Tuesday morning. At the meeting, we will show them how we used Conditional Fields to control which fields show up on the user registration form and how the fields change based on whether the user self-identifies as a legal aid advocate, pro bono professional, law student, or other. Advocates, with the use of the Register Pre-Approved module, automatically get upgraded permissions once they verify their email address so long as they register with one of the domains associated with a legal aid organizaiton. Law Students, using a rule through the (very useful) Rules module, get pro bono permissions automatically if they register with a .edu address. This functionality exists on our current site, primarily to make it
easier for law students to apply for internships through the PILI Law Student Internship application system we maintain.
On the administrative side, we used Adminstrative Views to alter the default Admin People view to return the field we need to see, created a rule to send a periodic email to our admins to review new users (and wrote a custom mail alter to turn off the automatic email every time someone registers), and set up an initial batch of roles
The Obstacle. One of the biggest parts of this week's sprint was the registration form. It sounded simple enough. And then I got to the part where I needed to collect who a user worked for. For advocates, that means a legal aid organization. And sure, a select list would have captured that information but on ILAO's sites, this field is more than just a text label of "Employer." When a user selects a legal aid organization as their employer, a relationship is created between the user and the organization: it adds them to a staff directory, and for some users associated with an organization, it gives them advanced rights to manage the organization's profile, their online intake settings, and their online applications for the Public Interest Law Initiative internship and fellowship programs. Furthermore, some content may be available only to members of a specific organization. I needed something more than a text field for organization: I needed an organization object or entity that will eventually contains the full profile of the organization sitewide. I knew I didn't want to create a completely standalone object, with its own database tables and administrative forms. So I started down a path to create a custom entity that would integrate with the Drupal Entity API. And I made progress on it.
The Community. But as it happened, I had plans that afternoon to cowork at a local Drupal shop for a few hours and then attend the Fox Valley Drupal meetup. When I was describing why I was going down the custom entity route, my fellow Drupallers started asking some questions: why isn't an organization just a node content type? does being a member of an organization get them something more than users who aren't members of an organization? how is the organization managed? how will a user get tied to an organization?
The Solution. The general consensus was that organizations could be treated as just another content type and that by setting it up that way, so that they are just nodes, we can take advantage of all of the cool node functionality already baked into Drupal, like displaying it as a page, node access controls, and because nodes are also entities, I could just use a form field type of entity reference to allow a user to tie themselves to the organization.
And here are the lessons I learned:
- Try to find the simplest solution. Because our organizations also have profile pages that display in a directory, require permissions to edit on a per-node basis (so that organization administrators can edit their organization's profiles and no others), and sometimes relate to other organizations, treating organizations as a content types means I don't have to build all that as part of a custom entity.
- Think about how the user will interact with the content. A custom entity is probably more approriate when we don't need all the overhead of a node and don't need to support editing, publishing to an absolute URL, and comments.
- If you aren't sure you are going down the right path, ask the Drupal communtiy for advice. Between local meetups, Twitter, IRC and the forums at Drupal.org, there is a large community of folks happy to point you in the right direction.