Add Eventlite exporter#2
Merged
Merged
Conversation
Adds support for exporting Eventlite sites to the convention JSON format, one export file per Eventlite event. - New `rake export:eventlite` task (requires EVENTLITE_DB_URL; optional DOMAIN_SUFFIX, TIMEZONE, FILE_BASE_URL) - Exports users (Devise bcrypt passthrough, names inferred from tickets), user_con_profiles, tickets (active only), store_items, store_orders, CMS layouts/pages/files/navigation - Schema extensions: cms_layouts top-level collection, cms_layout_name on cms_page, provides_ticket_type_name on store_item, eventlite source_system value - PostgreSQL support via pg gem - Integration test suite (skipped without EVENTLITE_TEST_DATABASE_URL) - CI: adds PostgreSQL 16 service alongside existing MySQL Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
In some Eventlite databases (including production), tickets were created without a linked user account — the attendee name and email are stored directly on the ticket (tickets.email, tickets.name) and user_id is NULL. The previous exporter assumed all tickets had a user_id FK and silently skipped any that didn't, producing empty exports against real data. - Tables::Tickets: fall back to row[:email] when user_id is nil - Exporter#build_store_orders: same fallback - Exporter#build_profiles: same fallback - Tables::Users: emit synthetic user records for ticket emails that have no user_id and no matching user account; deduplicates against the users-table pass Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Each exported event now includes a single Run (as expected for a single_event convention) and a confirmed signup for every ticket holder. The event also gets a registration_policy with one unlimited 'attendees' bucket so signups have a valid bucket_key to reference on import. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
When an event has multiple ticket types (e.g. male/female character splits), map each ticket type to a registration_policy bucket instead of the generic single 'attendees' bucket. Bucket slots come from ticket_type.number_available when set. For attendees who bought multiple ticket types (e.g. a character ticket and a cabin add-on), one signup is created per person using the ticket type with the most available slots — so a cabin ticket (1 slot) never wins over a character ticket (15-25 slots). Single-ticket-type events continue to use a single unlimited 'attendees' bucket as before. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
required_for_signup only applies to convention-mode sites. Single-event sites must use ticket_per_event instead. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The single_event content set provides the 'Regular event form' that EventCategory requires. Without it the import fails with a validation error on event_form. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Pages using {% ticket_form %} (Eventlite's registration form tag) can't
be imported into Intercode since that tag doesn't exist there. These
pages serve Eventlite-specific functionality that Intercode handles
natively, so skipping them is the right behaviour.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Pages skipped due to Eventlite-specific tags (e.g. ticket_form) now also have their navigation links removed. Both Pages and NavigationItems share the tag-detection logic via a new eventlite_only_content? helper on the base Table class. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
TicketType.name must be a word-character identifier. Eventlite names like "Female character" and "2-occupancy cabin" fail that validation. - slug_for() converts names to lowercase underscored identifiers - Ticket types export with name: slug and description: original_name - ticket.ticket_type_name, store_item.provides_ticket_type_name, and signup.bucket_key all use the slug - store_item.name and store_order.store_item_name keep the human- readable original name since they're display text, not identifiers Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Users with no name data now fall back to their email prefix as first_name, satisfying Intercode's Name presence validation. For multi-ticket-type events, tickets are deduplicated to one per user (best by available slots), preventing the unique user_con_profile constraint violation. Store items no longer carry provides_ticket_type_name since tickets are handled explicitly via the tickets array; losing ticket purchases remain as store orders only. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…name - Export default_layout_name and root_page_slug instead of raw layout content so the import service can wire up convention.default_layout and convention.root_page after CMS content is imported - Use event name directly as the convention name (was falling back to site_settings.site_title which gives the org name, not the event name) - NavigationItems: use navigation_section_id for proper section/link grouping instead of flattening everything into one "Navigation" section; standalone top-level links each become their own single-link section Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Reflects the fix that uses the email local part as first_name when both names are blank, so Intercode's name presence validation doesn't fail. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Purpose
Adds support for exporting Eventlite sites to the convention JSON import format. Eventlite is a lightweight Rails ticketing CMS, and this exporter maps its data model onto Intercode's import schema — one export file per Eventlite event (each becoming an Intercode `single_event` convention).
Changes
💻 New exporter
📐 Schema extensions
🔧 Infrastructure
Risks
The `cms_layouts` and `provides_ticket_type_name` fields are new schema additions that Intercode's importer doesn't yet consume — they'll be silently ignored until the follow-up Intercode PR lands. Everything else maps to fields the importer already handles.
🚢
🤖 Generated with Claude Code