Laravel Courses Laravel Package

Product Decisions This Supports

• Selling courses with a real checkout, not a client-side gate. v0.3.0 closes a hole where POST enrollments would self-enrol anyone into anything, letting a learner walk around your payment flow with a single request. The GatesSelfEnrollment contract (default FreeEnrollmentOnly) now means priced courses are enrolment-by-server-only: you call EnrollmentService::enroll() after payment confirms. This is a product decision you can now defend in a security review, and it makes "free trial / free audit" vs "paid seat" a first-class distinction rather than an honour system.
• Launching in-person and hybrid formats without a bespoke progress model. The attendances table plus courses.attendance_hours gives you completion-by-attendance, dispatched through the same ProgressService that completes on a passed final test. Course::requiredAttendanceHours() encodes the policy you actually want: on in_person, null means "all of hours"; on hybrid, only an explicit value counts, because there hours describes the whole course. That distinction is a product rule, and it's now expressible without custom code.
• Selling a course before the online material exists. The breaking change that stops an in_person course's lessons and tests from counting toward progress is, read as a product decision, the ability to sell in person first and author the e-learning later — drafting lessons no longer strands already-enrolled learners at 0%. If a course's lessons are meant to be completed, the answer is to make it hybrid, and that becomes an explicit catalogue decision rather than an accident of authoring order.
• Mixed-modality progress reporting for learners and ops. summary() gains hours_required, hours_attended, hours_percent, and overall_percent averages the online half and the attendance half when both exist (the units differ). This is what you need for a learner-facing progress bar that doesn't lie, and for an ops dashboard that can answer "who is close to finishing?" across formats.
• Integrity of issued certificates. Deleting an attendance row deliberately does not reopen a completed enrolment — "a certificate may already be out; withdrawing it is a revocation." That's a roadmap commitment you can make: completion is durable, and un-completing is a separate, auditable act. Equally, an in-person course with no hours set never auto-completes ("nothing to reach is not the same as reaching it"), leaving admin completion as the escape hatch for non-standard cohorts.
• Build vs buy. You are buying the enrolment state machine, the progress arithmetic across mixed units, the attendance ledger, and the completion triggers. You are still building the checkout, the payment-to-enrolment handoff, any membership-based self-enrolment policy, and every UI. That's a favourable split — the fiddly, easily-wrong part is the part you're not writing.
• Roadmap sequencing signal. A 0.x package shipping two breaking changes in one release is telling you the domain model is still settling. Plan adoption around pinned versions and a review of each minor release, not around "it'll be stable by the time we need it."

When to Consider This Package

Adopt when most of the following hold:

• You run courses with more than one completion mechanic — lessons and tests, in-person attendance, or both — and you want one progress number rather than three.
• You sell at least some courses, so the self-enrolment gate is a security requirement rather than an inconvenience. You must be willing to own the post-payment EnrollmentService::enroll() call; this release explicitly makes that your job, not the package's.
• You can tolerate a 0.x API. Two breaking changes in v0.3.0 means you budget for reading release notes before every upgrade, and you pin exact versions in composer.json.
• You can run migrations and backfill policy, since GatesSelfEnrollment changes behaviour on deploy: any priced course that previously relied on open self-enrolment will start refusing learners the moment you upgrade. If you have live traffic and a membership model, you need to bind a custom gate before you ship.
• You need admin-only attendance entry, with learners unable to record their own hours. If you wanted self-service check-in (QR codes, geofencing, learner-submitted hours), this package deliberately doesn't do that and you'd be building it on top.
• Your catalogue is modality-stable or you can reclassify it. Any existing in_person course whose lessons currently count toward progress will see that progress change on upgrade — if those lessons are load-bearing, you must switch the course to hybrid as part of the release.

Look elsewhere when:

• You need SCORM/xAPI, competency frameworks, or accreditation-grade audit trails. This is a pragmatic progress model, not an LMS compliance layer.
• You need partial-credit or revocation workflows for certificates. The package is explicit that deleting attendance does not reopen completion, and that withdrawal is a revocation you own.
• You need priced-course self-enrolment as a first-class feature — memberships, seat licences, cohorts — and don't want to own a GatesSelfEnrollment implementation.
• You need stable APIs and semantic-versioning guarantees. Come back at 1.0.
• Your in-person delivery has fine-grained session scheduling (rooms, instructors, capacity, waitlists). attendances is one row per session with a date and hours; scheduling is out of scope.

How to Pitch It (Stakeholders)

To executives: this release turns two product ideas we couldn't previously ship into configuration. First, we can now sell courses safely — a learner can no longer bypass checkout with a single request; paid enrolments are created server-side only after payment confirms. Second, we can run in-person and hybrid courses with real completion tracking, backed by an attendance ledger and an hours requirement, reported through the same progress summary learners already see. It also unlocks a commercial sequencing we wanted: sell a course in person now, author its online material later, without stranding the people already enrolled.

To engineering: the package handles the enrolment state machine, mixed-unit progress arithmetic, and completion triggers; we own checkout, the payment-to-enrolment handoff, UI, and any non-default enrolment policy. Be clear about the two breaking changes: (1) POST enrollments no longer admits learners into priced courses — the new GatesSelfEnrollment default FreeEnrollmentOnly enforces this, existing enrolments are returned without asking, and we must call EnrollmentService::enroll() post-payment (bind a custom gate if a membership model needs otherwise); (2) in_person lessons and tests no longer count toward progress — reclassify affected courses to hybrid. Attendance routes are admin-gated by design; learners cannot record their own hours. overall_percent averages online and attendance halves when both exist; online-only is unchanged. Deleting an attendance row does not reopen a completed enrolment, and an in-person course with no hours set never auto-completes — both are intentional, and we should treat certificate withdrawal as a separate revocation feature if we ever need it.

To customer success / ops: admins record attendance against an enrolment; completion fires when required hours are reached, using the same trigger as passing a final test. Two things will look like bugs but aren't: removing an attendance record won't un-complete a learner who has already finished, and a course with no attendance_hours set will never complete on its own — it needs an admin completion. Flag any course still marked in_person that has lessons people are meant to finish; those need to become hybrid before release.