Nova Text Copy Field Laravel Package

Product Decisions This Supports

• Whether to invest in internal-tooling UX at all. This package is a forcing function for a question most roadmaps never ask explicitly: how much friction should we remove from admin workflows where staff repeatedly lift identifiers out of Nova? v1.5.0 extends the copy-to-clipboard affordance from index/detail views into create/edit forms (#26) — the exact moment a freshly generated API token, invite link, webhook secret, or account ID needs to leave the screen and land in a ticket or config. The PM decision is not "should we install this," it's "do we care about transcription errors on operator surfaces?" If yes, this is a nearly free way to act on it.

• Build vs. buy for admin-panel niceties. The honest framing is a tiny third-party dependency versus ~100 lines of a custom Nova field we own, build, and maintain. Buying is defensible only if you accept single-maintainer risk and Nova-version coupling; otherwise vendoring the component is the cheap, durable answer. Either way this is a low-stakes decision that should not consume roadmap energy — make it a policy call, not a project.

• Standardizing a "copyable value" convention across resources. If the roadmap includes support consoles, onboarding flows, or account-provisioning tooling, there's a real case for a consistent field pattern instead of hand-rolling per resource. This package is one candidate implementation — but the convention is the decision, and it's worth standardizing regardless of which implementation wins. A one-file internal wrapper (CopyableValue extends TextCopy) makes the convention durable and makes swapping implementations a single-line change.

• Drawing a scope boundary the org will otherwise blur. Fit is where the copied value is convenience-sensitive but not highly classified — IDs, public links, keys shown once at creation. This is not a secrets-management control: no masking, reveal-on-demand, audit trail, or rotation. Do not let it be positioned internally as a security feature. Getting that boundary wrong is the only way this small dependency becomes a governance problem.

• Dependency triage and adoption prioritization. 69 stars, zero dependents, last release March 2019, no multi-maintainer stewardship. That profile supports a clear call: opportunistic adoption on an internal panel, inappropriate as a validated strategic dependency. Treat it as "cheap, useful, disposable" — and plan the disposal path before adoption, not after.

• Where to place the affordance (index vs. detail). For support/ops desks, the highest-value placement is often the index, so an operator reading a ticket can copy an account ID without opening the record. That's a product decision about workflow, and it hinges on whether the component implements IndexField — a technical detail with a direct UX consequence. Verify before promising it.

When to Consider This Package

Adopt when:

• You run Laravel Nova and have verified the field compiles and renders against your Nova major version. This is a hard gate, not a formality — Nova's frontend has moved (Vue 2 in Nova 3, Vue 3 in Nova 4+), and a stale field bundle is the most likely breakage point. Check composer.json constraints and prove it in a dev environment before writing it into a resource.
• Operators demonstrably transcribe values by hand today (IDs, slugs, external account numbers, invite URLs, one-time tokens) and transcription errors have a real cost — support tickets, misconfigured integrations, wasted minutes per interaction.
• The values are read-only and non-classified. Display-only (->onlyOnDetail()->readonly()) is where this field is safest and most useful; resolveUsing() for derived strings (e.g., a full invite URL) is the sweet spot.
• Your admin panel is HTTPS in every environment that matters. navigator.clipboard requires a secure context; over plain HTTP the button can fail silently, generating tickets that look like bugs.
• You can accept the maintenance terms: pin 1.5.0, name an owner, record it as disposable in the dependency register, and review on every Nova major upgrade rather than on a calendar.
• You keep a one-line exit ramp: a resource using plain Text::make() instead, or an in-house nova:field replacement of ~100 lines. Both are hours, not days.

Look elsewhere when:

• You are not on Nova, or you're on a Nova major the 2019 bundle doesn't support and you don't want to patch or port the Vue component.
• The value is genuinely sensitive and needs masking, reveal-on-demand, audit logging, or rotation. The copy button is the wrong affordance and will lull reviewers into thinking the secret is handled. Keep secrets out of Nova fields.
• You depend on richer Text behaviors — displayUsing(), asHtml(), index truncation, custom withMeta() props. This is a subclass with its own Vue component; the component author's props, not Nova's, decide what works. Use plain Text and accept the missing button rather than hacking around it in the resource.
• You need vendor support, an SLA, or multi-maintainer stewardship. Zero dependents and no release since March 2019 is a "convenience dependency" profile only.
• The workflow requires copyable values on create forms for values generated at save time. An empty token column copies ""; either generate pre-render in a model observer and route the operator to detail, or scope the field to detail only.
• Accessibility is a hard requirement with no capacity to verify it. Tab focusability, screen-reader announcement ("copy"), and a non-color-only success state are routinely missing from icon-only copy buttons from that era — check by hand once, and budget a fix if it fails.

How to Pitch It (Stakeholders)

To executives — the one-paragraph version: This is a small, free UI addition to our internal admin panel that gives staff a one-click copy button on values they currently retype by hand — account IDs, invite links, slugs, one-time tokens. It reduces transcription errors on operator surfaces at essentially zero cost and zero roadmap impact. It is explicitly not a security or secrets-management feature: it adds no masking, audit trail, or rotation, and we will not position it as one. We are treating it as disposable — pinned to a single version, owned by one person, and reviewed whenever we upgrade Nova, with a one-file replacement path if it breaks. The decision before us isn't "should we install this," it's "do we care about operator friction on admin screens?" If yes, this is the cheapest possible way to act on it, reversible one field at a time.

To engineering — what we're actually asking for:

• Scope: one resource, one read-only detail field as the first smoke test. Swap the import and the field; change nothing else. Keep adoption reversible line by line.
• Gates before wider rollout: confirm the bundle works on our Nova major; confirm HTTPS everywhere the copy action matters; confirm the button renders when the field is readonly() on a form (the combination we'll actually use, and the least likely to be covered upstream).
• Pattern: standardize via an internal CopyableValue wrapper extending TextCopy so the label, visibility, and accessibility text live in one file. That wrapper is also the exit ramp.
• Hygiene: pin 1.5.0 (not ^1.5), add it to the dependency register marked disposable, run nova:publish + hard refresh after any change, and verify accessibility by hand once (tab focus, screen-reader label, visible success state).
• Known failure modes to expect: silent no-op over HTTP, empty values on create forms, Text behaviors that don't carry over, and aggressive asset caching masking changes. Each has a documented workaround; none is a blocker.

The ask: approve as a policy-level, low-stakes convenience dependency — not a project, not a security control — with the explicit understanding that it is reviewed at every Nova major upgrade and replaced rather than rescued if it breaks.