Pumukit Teams Bundle Laravel Package

Getting Started

Read this first: teltek/pumukit-teams-bundle is a Symfony bundle, not a Laravel package — it ships PHP classes, a DependencyInjection/ folder, and service wiring for PuMuKIT, which is a Symfony application. If you are evaluating this from a Laravel codebase, it will not install or function; there is no adapter, no service provider, and no Laravel contract. The "Laravel developer" framing is a template mismatch — treat this assessment as if you are working inside an existing PuMuKIT deployment.

Minimal steps to first value:

1. Confirm you already run PuMuKIT. This bundle is an import pipeline into PuMuKIT's multimedia-object model; it is useless standalone. Check composer.json in your PuMuKIT root for the Symfony version — PuMuKIT has historically tracked Symfony 3.x/4.x, so your PHP constraint (likely 7.x) will gate what this bundle supports.
2. Install:

   composer require teltek/pumukit-teams-bundle
   

   If Composer resolves a dev branch or a constraint conflict against your PuMuKIT version, stop — you are probably looking at an unmaintained fork point and will need to vendor it manually.
3. Register the bundle: add it to app/AppKernel.php (legacy Symfony) or config/bundles.php (Symfony 4+) inside the appropriate environment block.
4. Where to look first, in this order:
   • README.md — the only usage doc that exists for a 0-star package.
   • DependencyInjection/Configuration.php — this file is the config schema. Every option the bundle accepts is defined here; the README will be incomplete, this file will not.
   • Command/ — the CLI entry points. This bundle has no meaningful UI surface; everything is driven from console commands, which tells you the intended workflow is cron-driven, not user-facing.
   • Resources/config/services.xml (or services.yaml) — what actually gets wired, and what you can override.
5. First use case to target: import a single Teams recording into one PuMuKIT series manually, end-to-end, before touching any scheduling. You want to see: Graph API auth succeeds → recording downloads → a PuMuKIT multimedia object appears → it transcodes → it is visible in the catalogue. Only then automate.

Implementation Patterns

The auth model is Microsoft Graph, so start at the Azure portal, not in PHP. Teams recordings are not stored in a Teams-specific store — they land in OneDrive/SharePoint (/users/{id}/drive/items/... or via onlineMeetings/{id}/recordings). You will need an Azure AD app registration with application-level permissions such as OnlineMeetings.Read.All and Files.Read.All, and a client-credentials flow. Whatever config keys the bundle exposes, they will map to tenant_id / client_id / client_secret. If the bundle's Configuration.php only exposes a subset, plan on a small wrapper service rather than forking.

Discovery → download → ingest is the pipeline shape. Expect to write three thin layers around the bundle:

• Discovery: enumerate recordings per user/meeting. The bundle may only handle a single known recording ID, in which case you supply the discovery loop yourself using Graph.
• Download: large MP4 files. Do this in the console context with generous memory_limit and max_execution_time, or stream to disk rather than buffering — Teams recordings are routinely 500MB–2GB.
• Ingest: hand the file to PuMuKIT's multimedia-object creation path. PuMuKIT transcodes on ingest, so create the object with a WAITING/PENDING status and let Symfony's async worker pick it up rather than blocking the command.

Idempotency is your responsibility. There is no built-in dedupe worth trusting in an unmaintained bundle. Store the Graph item ID (or a hash of the drive item's eTag) against the PuMuKIT multimedia object ID in a small table or in a PuMuKIT metadata field, and check it before every import. Without this, one cron overlap produces duplicate catalogue entries that are painful to merge.

Metadata mapping is the real integration work. Map Graph's recording metadata to PuMuKIT's model deliberately:

• Meeting subject → multimedia object title
• createdDateTime → recording date (PuMuKIT sorts and filters on this)
• Organiser → people/authors field
• Meeting ID → a series mapping rule (e.g. per-course or per-team series)

Do this in a dedicated service, not inline in a command, so it can be unit tested and re-run.

Schedule it, don't click it. Wire the command into cron or a Symfony scheduler at a low frequency (hourly is usually sufficient). Each run: discover new recordings since last cursor, check idempotency, enqueue imports. Keep the run short and make it restartable — long-running imports that die halfway leave partial objects.

Token caching matters at volume. Do not authenticate against Azure per file. Acquire one token per run and reuse it; if you import in batches, acquire per batch with an expiry check. Auth round-trips dominate cost on many-small-files workloads.

Gotchas and Tips

• This is not a Laravel package. No config/pumukit-teams.php, no facade, no php artisan. If your environment is Laravel, this evaluation ends here — the honest answer is "incompatible," and 0 dependents (see below) confirms nobody has bridged it.
• 0 stars, 0 dependents, 0 downloads-ish = effectively unmaintained. Do not assume the README is current, do not assume the Composer constraints are clean, and pin the exact version you test against. Expect to fork, vendor a copy into src/, and patch it. Budget for that in your estimate — it's not an "install and go" dependency.
• PuMuKIT version coupling is the most likely failure point. PuMuKIT's internal APIs for multimedia objects and series have shifted across releases. If composer require explodes with constraint conflicts, the bundle targets an older PuMuKIT than yours, and you are looking at a port, not an integration.
• Teams recordings expire. Microsoft 365 retention policies (commonly 60 or 120 days, sometimes 21) will delete the source recording out from under you. If your sync job misses more than the retention window, the content is gone permanently. Run the sync frequently and alert on failures — this is a business-continuity issue, not a maintenance annoyance, if the recordings are lecture content.
• Graph throttling on batch imports. Graph will 429 you on drive enumeration and file downloads at scale. Handle Retry-After headers explicitly; the bundle almost certainly does not.
• Large-file failure modes are silent. PHP memory exhaustion during download and transcode-timeout are the two most common failures, and both tend to leave a half-created multimedia object. Add a cleanup step that removes orphaned WAITING-status objects older than a threshold.
• Config quirks live in DependencyInjection/Configuration.php, not the README. Read node names and defaults there before assuming an option name. If a needed Graph setting isn't exposed, the clean extension point is a Symfony service decorator or a compiler pass overriding the bundle's service definition — not editing the vendored bundle, unless you have already accepted the fork.
• Debugging order: (1) run the command with -vvv and confirm config is loaded, (2) hit Graph manually with curl using the same credentials to isolate auth from PHP, (3) log the resolved multimedia-object payload before PuMuKIT ingest to catch mapping errors. Do not start by reading the bundle's internals — start by isolating which of the three pipeline stages (auth / download / ingest) is failing.
• Extension points to prefer: override service definitions in your app's services.yaml, decorate the importer service if the bundle exposes one, or wrap the console command in your own command that adds idempotency and metadata mapping. Forking the import logic should be a last resort, but for a 0-star bundle it is a realistic one.