Events For Laravel Laravel Package

Product Decisions This Supports

• Feature/roadmap scoping for event ticketing and RSVP flows. The package owns the full lifecycle a paid-event product needs: schedule and RSVP windows, sale windows, holds and checkout requests, waitlists and automatic promotion, check-ins (including scans by code), reminders, guests/party size, co-hosts, tiers, categories, labels, posters, and JSON-LD output. A PM can map roadmap epics (paid ticketing, waitlist fairness, door operations, refunds) directly onto existing primitives instead of commissioning them.
• Build vs. buy. 1.1.0 is the kind of release that argues for buy: it fixes correctness bugs a team would otherwise discover in production — MySQL TIMESTAMP overflowing at 2038 and DST spring-forward write failures (now DATETIME via migration 0008), timezone-aware events.schedule.max_duration, price/currency validation returning 422 instead of 500, numeric ticket-type keys no longer colliding with IDs, and immutable-date TypeErrors. These are unglamorous, expensive-to-find defects; the maintenance surface is exactly where a package earns its keep.
• Policy and product-rule definition. Several 1.1.0 changes are product rules, not just code: confirm() without a payment reference now means "paid another way" (cash at the door) and drops the online checkout; a going or held attendee adding guests can no longer take seats a waitlisted party of that ticket type would fit; rescheduling an announced event into an already-ended date is refused; leaving going clears check-in so a returning attendee checks in fresh and may decline again. These are documented, testable behaviors a PM can put in a spec and defend in a design review.
• Access-control and data-exposure decisions. PATCH /events/{event}/attendees/{rsvp} now checks manageAttendees before anything else, closing a leak where an empty body returned the managers' view of an RSVP to any signed-in user. Read routes now recognize the guards named in events.routes.auth_middleware (e.g. Sanctum tokens), so API callers no longer read as guests. Both matter for security sign-off and for privacy commitments in customer contracts.
• Test-harness credibility for acceptance criteria. Events::fake() now records builder chains (AddCoHost, CreateTier, SetPoster, Categorize, AttachLabels), records an attendee's own payment request so assertPaymentRequested() behaves after a paid RSVP, and tightens co-host/undo/check-in assertions so they no longer pass for no-op calls. PM-authored acceptance criteria like "co-host gets notified" or "checked-in count is right" are now actually assertable rather than vacuously green.
• Refund and reconciliation design. Force-deleting an attendee (and events:repair --orphans) now announces each released RSVP with RsvpChanged plus RsvpCancelled carrying wasPaid — a previously missing refund trigger. A stale checkout requested against a refreshed hold is discarded with RsvpPaymentRequestDiscarded instead of confirming a larger party with a smaller payment. Both are direct inputs to finance/support runbooks.
• Migration planning input. 0008 rebuilds the package's tables on MySQL/MariaDB — a scheduled, non-trivial operational event that needs a maintenance window, a connection-settings check (stored values convert in the session timezone that wrote them), and a note to republish migrations and add UseConfiguredGuard if routes/events.php was published. Roadmap the upgrade like a release, not a composer update.

When to Consider This Package

Adopt it when:

• You need first-class event scheduling with paid RSVPs, holds, sale windows, and waitlists — including promotion fairness as a stated product rule.
• You run MySQL or MariaDB and care about dates beyond 2038 or DST-heavy locales; 1.1.0 makes those safe, and events:doctor warns while the table still stores TIMESTAMP.
• You want door operations (check-in by code, undo, checked-in lists scoped to going RSVPs) and manager-mediated cash/terminal payments alongside online checkout.
• You need Events::fake()-based tests to back acceptance criteria, especially around co-hosts, tiers, labels, and payment requests.
• You expose events over an API and want stable, round-trippable host type aliases (user rather than User) that match the aliases used in request bodies and alias:key paths.

Look elsewhere or proceed carefully when:

• You are on 1.0 and cannot tolerate the upgrade work: republishing migrations, an on-MySQL table rebuild, the confirm() semantics change, the waitlist-over-guests rule, and the resource type change from class basename to alias. Hosts that compared type against the basename must update their code or override events.resources.*.
• You have published routes/events.php and cannot add UseConfiguredGuard to its outer middleware group — read-route authorization will be wrong until you do.
• You depend on a hold's original checkout surviving a party-size or ticket-type refresh, or on confirm() without a reference leaving an online checkout payable. Both are now intentionally discarded.
• You need multi-tenant or non-Laravel stacks, or you require a single-vendor commercial SLA — this is an open package whose upgrade cost you own.
• Your date model is immutable (Date::use(CarbonImmutable::class)) and you pinned an earlier version for that reason; 1.1.0 fixes it, so this is a reason to upgrade rather than to leave.

How to Pitch It (Stakeholders)

To executives: 1.1.0 is a hardening release for the paid-events capability, not a feature grab. It removes two classes of production risk we would otherwise own — MySQL timestamp overflow at 2038 and DST-related write failures — closes a data-exposure hole on the attendee endpoint, and fixes refund and check-in accounting so support and finance see accurate wasPaid signals. The cost is one scheduled migration on MySQL/MariaDB (a table rebuild) plus a short upgrade checklist; the benefit is that ticket sales, waitlists, door check-in, and refunds rest on behavior the package now tests.

To engineering: Plan the upgrade as a release: republish the events-migrations tag to add 0008, run migrate with the same connection settings the app uses so stored instants convert in the timezone that wrote them, then run events:doctor to confirm no TIMESTAMP remains. If routes/events.php is published, add UseConfiguredGuard to the outer middleware group. Expect four behavioral deltas to test against: confirm() without a reference now means cash/other and drops the online checkout; guests added to a going or held RSVP can no longer absorb seats a waitlisted party would fit; default resources render host type as the user alias rather than the class basename; and rescheduling into an already-ended date for an announced event is refused with 422. The rest of 1.1.0 is fixes — immutable dates, numeric tier keys, price/currency validation, timezone-aware max duration, exact event length preservation, check-in clearing on status change, guard-aware reads, and stricter Events::fake() assertions — which means some previously passing tests may now correctly fail.