https://git.drupalcode.org/project/tms
Project overview
The module is listed on Drupal.org as Ticketing Management System (TMS). drupal.org
It “provides ticketing (and more abstractly, entities), may have multiple ticket types, each with a unique set of requirements fields. This allows users to submit tickets … Users can set the status, priority, and type of each ticket submitted.” drupal.org
The latest stable release is version 1.0.1 (December 1, 2024) which supports Drupal ^10 || ^11. drupal.org+1
According to the GitLab repository there are only 4 commits, 1 branch, 2 tags. GitLab+1
The project was “Created on August 15 2022”. GitLab+1
As of the project page, usage is small (~37 sites). drupal.org
What it does (core functionality)
The module defines “Ticket types” (similar to content types) with custom fields per type. (From project page) drupal.org
There’s a UI for admin to configure ticket types and their fields.
Users can create tickets (via a content‑type or entity) filling in the fields defined by their type.
The tickets have attributes like status, priority, type.
On the project page it mentions: “Your new content will have a Ticket tab. Click the tab to view information about the Tickets.” drupal.org
Things to note / potential deficiencies
Very small commit count / minimal activity means it may be light on features, unit tests, edge‑cases, robust UI.
Given its small usage base (~37 sites) there may be fewer battle‑tested integrations, and less community support.
Might not yet integrate with workflow automation, advanced notifications, taxonomy references, or external issue trackers, which in your use case (extending for RSVP system + ECA workflows) you’ll likely want.
Limited documentation (nothing detailed on project page beyond basic configuration).
Given the low commit count, you’ll want to perform a deep code audit (as you plan) to ensure quality, extendability, and identify where you’ll need to add/modernize.
🔍 Suggested Audit Checklist
Since you’ll be extending and integrating this module into your broader RSVP system (with taxonomy, entity references, workflows, etc), here’s a structured audit you should perform:
1. Architecture / Entities
Identify the main entity type(s) defined by the module (e.g., Ticket entity, TicketType entity) and how they map to Drupal’s Entity API.
Check how the Ticket types (as configuration) are implemented — Are they using ConfigEntity, Content Entity, or simply content types?
Check the fields: how are custom fields per TicketType handled? Is it using the Field API, and is it dynamic/extendable?
Look for taxonomy or reference fields: Are there built‑in references (e.g., status, priority) or is it fixed/enumerated?
Examine the permissions/roles architecture: how is “who can create tickets”, “who can update status” handled?
Check for revision support, translation/multilingual support (if relevant).
2. Data Model & Storage
Inspect the database schema: how are tickets stored (tables, entity tables), how types are stored.
Check indexing/efficiency of queries (for listing/search/filtering of tickets).
Look for any custom tables vs standard Drupal entity tables.
Check for migration/updating path, especially if you’ll add new fields or extend types.
3. UI/UX & Forms
Evaluate the UI for creating and managing ticket types and tickets: form structure, validation, usability.
Check Views integration: Are there built‑in Views for listing tickets by type, status, priority?
Check if there is a “Ticket tab” on some parent content (as project page implies) and how that is tied in.
See how listing, filtering, sorting of tickets is done; any advanced features like dashboards, etc.
4. Workflow & Status / Transitions
Check how the “status” field is implemented: is it free‑form, or are there predefined statuses?
Are there triggers or events when status/priority change? (For instance, you may want to hook into those changes and trigger workflows or notifications).
Examine whether the module supports transitions (e.g., “open → in progress → resolved”) or just static statuses.
Look for hook implementations, event dispatchers, or ECA/Rules compatibility.
5. Integration Points
Check how the module integrates with other modules: e.g., Views, Rules, Entity Reference, Workflow modules, Notifications.
Are there extension points: hooks, plugin systems, services for ticketing operations?
Check for REST/JSON API endpoints (if planning integrations). If none, you may want to add those.
Check for taxonomy or entity reference capabilities — since you plan to tie into your “Community Taxonomy” model, you’ll want ticket types or tickets themselves referencing taxonomy terms.
6. Coding Standards & Quality
Review code for adherence to Drupal coding standards (PSR‑12, Drupal core style).
Check for namespacing, services, proper use of dependency injection.
Look for any deprecated APIs (especially if code started in 2022 and minimal updates) to ensure compatibility with Drupal 11 and future.
Check for tests: unit tests, kernel tests, functional tests. Probably there are few or none; a gap you’ll likely fill.
Review documentation: inline docblocks, README, comments; determine maintainability.
7. Extendability & Customization
Check how easy it is to add new ticket types, new fields; how modular is the architecture.
Check how you can override forms, change behaviours, add your own workflows.
Check how easy to expose ticket data in your taxonomy‑driven system (e.g., referencing ticket types or tickets from taxonomy terms or community entities).
Look for event dispatching or hooks when tickets are created/updated/deleted.
8. Security & Permissions
Evaluate access control: who can create/view/update/delete tickets of each type.
Check for input sanitisation, validation (especially important if tickets allow rich text or attachments).
Check for data exposure via Views or REST endpoints (if present) — ensure no unintended data leaks.
Check for update path / capabilities to apply patches or customisations in future.
9. Performance & Scalability
If you plan to use this for a home system (maybe small scale) this may be less critical, but still check: large number of tickets, filtering, indexing.
Are there caching mechanisms? Any heavy queries or loops on page load?
Check for N+1 queries in lists.
Evaluate whether you’ll need additional modules like Views Bulk Operations (VBO) for bulk ticket handling.
10. Documentation & Community Support
Review README (exists, clear instructions) and project page (some basics, but minimal).
Check for open issues, active maintainers. Note: small commit volume.
Assess risk if you take this module into production and then need to maintain/extend it long‑term yourself (you probably will).
Consider whether you might fork or become a maintainer of your own variant.
🛠 Initial Extension / Integration Ideas for Your Use Case
Since you’re working on a RSVP system with a central “Community Taxonomy” structure, and you plan to track tickets/issues in a home system, here are ways you might extend or integrate TMS:
Tie Ticket Types to Community Taxonomy Terms: e.g., have each community (term in your Community Taxonomy) have its own ticket type(s), or tickets reference the community term. That way issues/tickets are scoped to a community. Use an Entity Reference field from the ticket to the taxonomy term.
Workflow Integration: Use a module like Workflow or integrate with ECA (event‑condition‑action) modules to trigger notifications/status changes. For example, when a ticket is created for a community, send an email to community managers, or escalate if no update in X days.
Views/Lists by Community: Create Views listing tickets filtered by community term, type, status, priority. Add dashboards for community leads.
Notifications & SLA: If priority high, set due dates and send reminders. Maybe add “due date” field, and an automated ECA check for tickets nearing deadline. Extend TMS to include a ‘due date’ or integrate with a scheduler.
Reporting & Metrics: Add fields like “resolution time”, “ticket owner/assignee”. Build views/charts (maybe use Charts module) for metrics: open vs resolved, average time by community, by ticket type.
Permissions Scoped by Community: Only community members or leads see tickets for their community. So tie ticket entity’s access to the taxonomy term membership (use hook_entity_access or content_access modules, or field‑based access modules).
Custom Field Templates: If you have specialized ticket types (e.g., bug report, feature request, event issue, facility request), you may want different field sets or workflows. TMS claims to allow unique fields per ticket type — verify how it does so and potentially extend.
Integration with RSVP workflows: When a user RSVPs (via your RSVP system) to an event/meeting and later reports an issue (ticket) about that event, you might automatically link the RSVP record to the ticket. Perhaps add an entity reference from ticket to RSVP or event entity.
REST / API Exposure: If you foresee external tools (e.g., mobile apps or Slack integration) you might expose tickets via JSON:API and maybe allow status updates externally.
UI/UX polishing: Build an admin interface for ticket management, maybe integrate with your theme (you mentioned the GPL codebase for your theme is at https://github.com/slackstone/radix_rsvp). Make sure the ticket UI fits the theme and community branding.
Testing & Quality: Since the module is lightweight, you might add kernel/functional tests for your extended features, ensure backwards compatibility, and include upgrade path documentation.
🎯 My Recommendation / Next Steps
Here’s what I suggest you do next to move forward efficiently:
Clone the repository of the TMS module and set up a local dev environment (Drupal 10/11) and install TMS.
Explore the module’s architecture: review entity definitions, config schema, forms, hooks. Identify how ticket types are managed.
Map the module into your architecture: identify how it fits with your Community Taxonomy schema, RSVP system, and workflows. Sketch a simple diagram of how tickets, communities, and workflows will interact.
Identify gaps: Based on the audit checklist above, mark where TMS lacks features you want (e.g., due dates, assignee workflows, taxonomy references, API endpoints, custom statuses, bulk operations).
Plan your extension: Decide whether you’ll extend TMS via a custom module (e.g., radix_rsvp_tickets), or fork and enhance TMS directly (if fewer dependencies). Choose one that uses best practice: keep core module minimal, add hooks/plugins.
Define Recipes: Because you mentioned “Drupal Recipes”, you can document how to set up ticket types, link to communities, add fields, integrate notifications, etc. This can serve as internal documentation or a reusable pattern for other projects.
Design the UX: Based on communities + tickets, design how users will see tickets in context of their community, how workflows operate, how notifications appear.
Write tests & documentation: Ensure your extensions are well tested and documented (README, upgrade path, config export).
Iterate & deploy: Start with a minimal viable ticketing capability for your home system; then gradually add advanced features as needed.