Oc Easyaudit Plugin Laravel Package

Product Decisions This Supports

• Build vs. buy for the audit-log viewer, not the audit log itself. The decision this package informs is narrow but real: do we spend engineering cycles building an in-admin "who changed what, when" screen, or adopt an existing one? The underlying audit data model (event capture, retention, immutability) is the expensive part and remains ours either way.
• CMS platform selection. If audit visibility for content editors is a requirement, this tilts the Winter CMS vs. October CMS vs. plain Laravel evaluation. Note the package name (oc-) and repo (wn-) diverge — this is a Winter CMS plugin, and it is not droppable into an arbitrary Laravel application.
• Compliance roadmap scoping. Useful as a fast, cheap way to demo "editor accountability" to stakeholders and customers, and to decide whether an audit trail is a feature (nice-to-have transparency) or a control (SOC 2 / GDPR / regulated-content evidence). If it's a control, this package is a starting point, not a solution.
• Use cases it plausibly unlocks: multi-editor content sites needing attribution, incident forensics after a bad publish, editorial approval workflows, customer-facing "last modified by" transparency, and — as of v4.3.1 — plugin/config authors who need to register trackable overrides (dynamic properties) rather than editing plugin source.
• Roadmap sequencing. Low-cost spike candidate: validate demand for audit visibility before committing to a first-party build. It buys information cheaply.

When to Consider This Package

Adopt (as a spike, not a commitment) when:

• You are already running Winter CMS and have no intention of migrating off it in the next 12–18 months.
• Your audit need is operational, not evidentiary — internal accountability, debugging, "who broke the page."
• You have a small team and the alternative is no audit UI at all.
• You need to extend which fields/models are tracked without forking — v4.3.1 correctly honours trackable overrides registered as dynamic properties, so config/plugin-level extension is now a supported path rather than a source patch.
• You can vendor the source and pin the version (current: v4.3.1), treating it as code you may have to own.

Look elsewhere when:

• You're on plain Laravel. Use spatie/laravel-activitylog (or equivalent) plus a first-party UI; this plugin's value is CMS integration, which you won't get.
• Compliance is the driver. No tamper-evidence, no retention policy guarantees, no vendor SLA, no security review, and a NOASSERTION license — legal review is a hard gate before any production or customer-facing use.
• Ecosystem risk matters. 17 stars, 0 dependents, and a single-package maintainer — thin bus factor. Updated signal: v4.3.1 brings LukeTowers (the Winter CMS lead maintainer) in as a first-time contributor, which materially improves the bus-factor story and is a meaningful legitimacy signal for the Winter ecosystem. It does not, however, constitute a support commitment or SLA — still plan to fork and vendor.
• You need scale guarantees. Unknown performance characteristics under high-volume audit writes; benchmark before trusting it on a busy install.
• You need to audit anything outside Winter models. This is scoped to CMS models by design; v4.3.1 widens how you register tracked fields, not what can be tracked.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost Winter CMS plugin that gives editors and admins a readable "who changed what" view. It's a cheap way to test whether audit visibility is a feature customers actually ask for before we fund a first-party build. It is not a compliance product and should not be represented as one — treat any compliance framing as out of scope until legal clears the license and we add retention and tamper-evidence controls. Risk is contained and modestly improving: it's a plugin, not a platform dependency, it is removable, it is actively maintained (v4.3.1 shipped this cycle, with Winter CMS's lead maintainer now contributing), and the change is a small backwards-compatible bug fix with no schema or data migration implied.

To engineering: Thin admin layer over existing audit records — low integration cost. v4.3.1 is a patch release: it fixes dynamic-property trackable overrides not being honoured, so config-driven field tracking works without patching plugin source — adopt it, and confirm it covers any override pattern you rely on. Two standing caveats: the license is NOASSERTION, so get legal sign-off before it ships, and upstream is still a single-package maintainer with effectively no dependent base, so plan to fork and vendor rather than depend on upstream. Pin to v4.3.1, benchmark write overhead on a realistic dataset, and budget a small ongoing maintenance line. Recommend a two-week spike with a clear go/no-go on whether audit visibility is a real requirement; if it is, the likely outcome is adopting the data model and writing our own viewer.