Automating the IXP Initiative: A Technical Implementation with Drupal

Introduction

The IXP Fellowship Initiative is a community-driven effort within the Drupal ecosystem designed to help inexperienced Drupal developers gain practical experience through structured mentorship programs. The initiative recognizes individuals who have completed training but lack hands-on experience, addressing the common challenge of high-experience requirements for junior roles.

Organizations participating in the initiative commit to providing at least 160 hours of paid work and dedicated mentorship time. In return, they receive contribution credits for their investment in developing new talent. The program requires regular progress reporting and specific completion criteria to ensure quality mentorship and skill development.

At Palcera, we're supporting this important initiative by developing an automated platform to manage these engagements efficiently. This article details our technical implementation using three key Drupal modules: Group, Content Moderation, and ECA (Event, Condition, Action). We'll explore how these modules work together to create a seamless platform for tracking and managing IXP Fellowship engagements.

Building the Foundation with Group Module

Implementation and Challenges

The Group contributed module (https://www.drupal.org/project/group) provided our foundation for organizing companies and their participants. Our primary challenge was designing a role structure that would accommodate both company-specific permissions and site-wide administrative needs.

Solution Details

We implemented a dual-level role structure:

Group-Level Roles

• Company Admin: Full group management capabilities
  • Can create company (group)
  • Can assign users to the group
  • Can manage group content
• Company Member: Mentor-focused role
  • Cannot create companies
  • Can manage engagements and create progress reports
  • Typically assigned to mentors within the organization
• IXP User: Program participant role
  • Limited permissions within their assigned group
  • Can submit their own progress reports

Site-Wide Roles

• Administrators: Initiative leadership
  • Full site management capabilities
  • Can manage all groups and content
• IXP Reviewers: Volunteer reviewers
  • Can access all engagements
  • Authority to approve credits
  • Can be combined with administrator role

This structure required careful permission configuration to ensure proper access control while maintaining the flexibility needed for program management. The separation between group-specific and site-wide roles helped maintain clear boundaries of responsibility.

Workflow Management through Content Moderation

Content Moderation provided the perfect framework for tracking engagement progress. We implemented a state-based workflow that mirrors the actual IXP process:

States and Transitions

1. Engagement Proposed: Initial state for new engagements
2. Engagement Start: Active engagements
3. Final Review: Ready for evaluation
4. Needs More Info: Requires additional documentation
5. Approved: Successfully completed

The workflow allows company administrators and members to manage transitions through the first three states, while reviewers handle the final approval process.

Automation with ECA

The real power of our implementation comes from the ECA (Event, Condition, Action) contributed module (https://www.drupal.org/project/eca). This module allows us to create sophisticated automations without custom code, serving as a modern alternative to the legacy Rules module.

User Role Assignment

Our first automation handles user role assignment during registration:

• Users select their role through a custom field during registration
• ECA workflow checks if the role is already assigned
• Appropriate role is assigned based on selection
• We adapted the workflow from the ECA Guide's Add role to inserted or updated user example

Case Number Generation

We implemented a sequential numbering system:

• Utilizes a state variable to maintain the sequential counter
• Numbers are padded with zeros to create a five-digit format
• Generates case numbers in the format: IXP-[padded number] (e.g., IXP-00002)
• Initially implemented for a dedicated case number field
• Extended to modify content titles (e.g., "IXP-00002: Original Title")
• Includes validation to prevent duplicate case numbers and only modify titles when case number is empty
• Increments sequence counter after successful assignment
• Adapted from the ECA Guide's Get next incremental ID example

Report Tracking System

One of our more complex implementations involves two separate workflows for calculating and validating report submissions:

Progress Reports Calculation

• Converts both start and end dates to timestamps
• Calculates the total duration in seconds by subtracting start timestamp from end timestamp
• Divides the total seconds by the number of seconds in a two-week period to determine number of periods
• Expects two reports (company and IXP user) per two-week period
• Example: A 4-week engagement (2,419,200 seconds) requires 4 total progress reports (2 per bi-weekly period)
• Visual indicators (✓ or ❌) display whenever an administrator or IXP reviewer views the engagement

Final Reports Validation

• Only displays validation message when engagement is in "Final Review" state
• Validates presence of exactly two final reports (one from company, one from IXP user)
• Uses same visual indicator system as progress reports

End Date Automation

Our final automation handles engagement completion:

• Automatically sets end date when status changes to "Final Review"
• Triggers report calculation update
• Ensures accurate period calculations for report validation

Technical Challenges and Solutions

During implementation, we encountered and solved several technical challenges:

1. Sequential Number Management: Initially struggled with reliable sequence generation until we adapted the approach from ECA Guide's incremental ID example.

2. Report Calculation Display: Originally attempted using ECA Render for a custom block but simplified to status indicators for better usability.

3. Date Handling: Implemented fallback to current date when end date isn't set, ensuring calculations remain accurate throughout the engagement lifecycle.

Conclusion

This implementation demonstrates how Drupal's ecosystem of modules can be combined to create sophisticated automation systems without custom code. By leveraging Group, Content Moderation, and ECA, we've created a robust platform that efficiently manages the IXP initiative's requirements.

The system is currently handling engagements on a case-by-case basis, which suits the program's current scale. As the initiative grows, we can easily extend these automations to handle batch processing and additional requirements.

While this is still a work in progress, we wanted to share and show how, from the simplest to a complex Wrokflow, we can automate without having to create a custom module. Improving the updatability of the site.