Filament Qrcode Scanner Html5 Laravel Package

Product Decisions This Supports

• Build vs. buy for data capture. This package answers "how do operators get a barcode/SKU/asset ID into a Filament form?" without an in-house affix action, a scanner modal, and the Livewire wiring behind it. v2.1.3 is evidence of the hidden cost you'd absorb building it yourself: the scanner behaved correctly on editable forms and incorrectly everywhere else, and that only surfaced once someone scanned into a disabled field on a view page.
• Feature scope: where scanning is allowed to appear. The release makes "scan into a disabled field" a deliberate product decision instead of an accident. Default behavior is now fail-closed — no camera button, no modal, no write — which is the right default for read-only and view-page contexts (ViewRecord::defaultForm() renders the edit form with ->disabled()).
• Scan-only fields as a supported pattern. hideWhenFieldDisabled() legitimizes a real ops pattern: a field disabled to stop manual typing but kept in the payload with ->dehydrated(), populated exclusively by scan. That's a product decision (operators must scan, not type) that now has a clean implementation path rather than a hack.
• Trust in admin tooling. The underlying bug was a silent no-op: the scan modal called $wire.set() unconditionally, so the value changed on screen but the form could never save it. Users read that as "the app lost my scan." Fixing it is a reliability decision, not a cosmetic one — it affects whether floor staff believe the tool.
• Roadmap signal. v2.1.3 is hardening, not new capability. Treat the package as feature-complete for single-field capture and plan your own work around bulk/multi-item flows rather than waiting on the plugin.

When to Consider This Package

Adopt when:

• You're on Filament and have forms that accept a code — SKU, EAN/UPC, asset tag, order number, location bin.
• Operators carry phones or tablets; there is no dedicated hardware scanner in the workflow.
• The capture is one field at a time, inside an existing create/edit form.
• You want scanning to disappear automatically in read-only, disabled, or view-page contexts — which is now the default, not something you wire up.
• You're comfortable with a small, narrow-scope dependency where the vendor is absorbing Filament quirks (here: disabled being styling-only, and affix actions being filtered by isVisible() alone).

Look elsewhere when:

• You need high-throughput line scanning with hardware scanners. Keyboard-wedge input into a focused field beats a modal camera on every metric.
• You need bulk or session-based capture — receiving 50 units, cycle counts, multi-line picking. That's a dedicated screen or relation manager, not a per-field modal.
• You're outside Filament (plain Livewire, Blade, Inertia) — the action API won't transfer.
• You need control of the camera/decode stack, strict offline behavior, or device-side validation before the value hits the server.
• You require accessibility guarantees or hardened camera permissions review; a modal camera flow needs its own evaluation.

How to Pitch It (Stakeholders)

Executives: This is a small, low-risk dependency that removes a class of data-entry error and uses hardware staff already carry. The release we're reviewing fixes a trust-damaging bug — scans that appeared to work but silently couldn't be saved — on read-only and view screens. No migration, no config change, no new cost. Recommendation: adopt and pin.

Engineering: v2.1.3 is a non-breaking patch on the 2.x line. It fixes a case where BarcodeScannerAction stayed visible and clickable on a disabled field, because Filament never cascades disabled to affix actions and the modal calls $wire.set() unconditionally. The action now hides itself when its field is disabled, whether set on the field or inherited from its container. New hideWhenFieldDisabled() opts back in for deliberately scan-only fields (disabled for typing, ->dehydrated() into the payload). The guard is implemented by overriding isHidden() rather than calling ->hidden() internally, so a consumer's own ->hidden() condition composes instead of being silently dropped. Upgrade is safe; audit two things — existing ->hidden() conditions on scanner fields, and any scan-only fields that now need the explicit opt-out. Worth a regression test on a disabled view page.