Dynamically Configurable Mjr Bundle Laravel Package

Product Decisions This Supports

• Feature decision — expose integration config to non-engineers. The core idea (persisting MJR integration settings in a database and editing them through an admin UI instead of static config files) supports the decision to make third-party integration credentials and options editable at runtime. That's a self-serve ops capability: support or account managers change settings without a deploy, ticket, or engineer.
• Build vs. buy — buy the pattern, not the package. With 0 stars, 0 dependents, and a last release of June 2016, this is not an adoptable dependency. It is a reference implementation for "configurable vendor integration" and should be treated as a design input to a small internal build, not a procurement line item.
• Roadmap input — multi-tenant and white-label deployments. Runtime-configurable integration settings are the prerequisite for per-account/per-tenant credentials, customer-owned MJR accounts, and white-label installs where each client supplies their own keys. This package demonstrates the shape of that feature.
• Scope decision — which knobs are safe to expose. "Some aspects" of the integration is the right instinct: the bundle implicitly answers the product question of how much vendor configuration belongs in the UI versus in code. Use it to argue for a curated allowlist of settings rather than a raw config editor.
• Support-cost reduction. The business case is fewer config-change escalations and faster onboarding of new MJR-connected accounts. That's the metric to instrument if this feature is greenlit.

When to Consider This Package

Consider the pattern (not the code) when:

• You need MJR settings to be editable by non-developers, per environment or per tenant.
• You are already inside the Modera/Symfony admin ecosystem and want a familiar shape for a settings screen.
• You want a cheap sanity check on data model and UI surface before scoping your own implementation.

Look elsewhere — or rebuild — when:

• Your stack is Laravel. This is a Symfony bundle, not a Laravel package; there is no adapter path. In Laravel, the idiomatic equivalent is a settings model with encrypted casts, a Filament/Nova settings page, and config caching — roughly one to two weeks of work.
• Maintenance and security matter. A 2016-era, zero-adoption package touching third-party credentials and API integration is an unmaintained attack surface. No visible tests, CI, or release cadence; no security response path.
• The MJR service itself is uncertain. The package's lifespan is capped by the vendor's. Confirm MJR is still an active, supported integration on your roadmap before investing.
• You need framework-version support. Symfony 2.x/3.x-era code will not run cleanly on modern PHP; porting cost likely exceeds reimplementation.

Recommendation: do not add as a dependency. Cite it as prior art in the design doc, and build a thin internal version sized to the knobs you actually need.

How to Pitch It (Stakeholders)

To executives: This is a blueprint, not a purchase. It shows that integration configuration can be moved out of code and into the admin UI, which shortens customer onboarding and removes engineering from routine credential changes. The license cost is zero, but the maintenance risk of the original code is high — it hasn't shipped since 2016 and has no users. Proposed action: fund a small internal equivalent (1–2 weeks) rather than adopting it.

To engineering: Treat it as a reference for storing vendor integration settings in the database behind an admin form, with a deliberately limited set of exposed fields. It's a Symfony bundle from the Modera ecosystem, so it does not fit our Laravel stack and shouldn't be vendored. We'd reimplement idiomatically: a settings entity, encrypted credential storage, an admin UI, and cache invalidation on save.