Filament Issabel Click To Call Laravel Package

Getting Started

This is the first stable release, so treat the assessment as provisional: the package ships three surface areas (AMI click-to-call, a call viewer wired to the filament-click-to-call context, and a publishable dialplan tag), and day-to-day usage is concentrated in the first two.

1. Require the package and publish its assets:

   composer require <vendor>/filament-click-to-call
   php artisan vendor:publish --tag=filament-click-to-call-config
   

2. Put AMI credentials in .env (host, port, username, secret, and the dialplan context to originate into). Keep them out of the repo — this is a telephony credential with dial privileges.
3. Register the plugin on the Filament panel you want the click-to-call affordance on, and only that panel, before layering multi-tenant logic.
4. Look first at: the package README (for the exact plugin/action class names), config/click-to-call.php, the Filament plugin class in src/, and the published dialplan tag under resources/.
5. First use case: a Contact (or Lead) resource with phone numbers — attach the click-to-call action to the table row and/or the infolist header, so an agent clicks a number and Asterisk originates the call to their extension, then bridges to the contact.

Implementation Patterns

• Action placement. The natural integrations are a table row action, a bulk action (careful — see Gotchas), an infolist header action, and a form-header action on the view/edit page. Prefer a single reusable action class configured with the phone field, so every resource behaves identically.
• Context is the routing contract. The filament-click-to-call context name is what ties the Filament side to the Asterisk dialplan. Define one context per routing policy (per tenant, per panel, per trunk) rather than one global context; the action should resolve the context from the current panel/tenant, not hardcode it.
• Dialplan publishing is a deploy step. Publish the tag, include the generated snippet in extensions.conf (or an #included file), then reload the dialplan before the first call. Automate this in your deploy script; a published-but-not-reloaded dialplan is the most common "it does nothing" failure.
• Normalize numbers at the boundary. Store numbers in E.164 and convert to the dialplan's expected format in one place (a small value object or a config-driven formatter). Mixing formats across resources is where click-to-call silently misdials.
• Gate by policy, not by visibility. Wrap the action in ->visible()/->authorize() against a policy or permission. Outbound dialing costs money and can reach real people; treat it like a destructive action.
• Viewer integration. Use the viewer for call context (who/what/when), not as an analytics surface. If you need reporting, source it from CDR/AMI events rather than from the viewer's state.
• Queue when the UI must stay responsive. AMI Originate is a network call to Asterisk. If the action runs synchronously in the Livewire request, wrap it in a queued job and reflect state via Filament notifications or polling.
• Test with a fake transport. Bind a fake AMI client in tests and assert on the originate payload (channel, context, extension, caller ID) rather than opening a socket. Use Http::fake()-style determinism so CI never touches a real PBX.

Gotchas and Tips

• 1.0.0 is "stable" but unproven. It's the first tagged release; pin the version and read the diff of the config file on upgrade rather than assuming vendor:publish --force is safe.
• AMI is not HTTP. No retries-by-default, no meaningful status codes, and failures often surface as a timeout rather than an error. Set an explicit connect/read timeout and log the raw response; a hang in the Livewire request looks like a frozen button.
• Firewall and manager.conf. Port 5038 is normally closed. The AMI user needs permit= for your app server's IP and read=call,originate / write=originate — a correct secret with the wrong permit line is indistinguishable from a wrong password in the error you get back.
• Config caching. php artisan config:cache in production means .env changes to AMI credentials have no effect until you re-cache. Bake credentials in at deploy time and verify with a health check.
• Dialplan reload. After publishing the tag, run dialplan reload (or the AMI Command action) — and confirm the context actually exists with dialplan show <context>. If the context is missing, Originate fails and the call is silently dropped.
• Bulk actions can originate a room full of calls. Rate-limit or forbid bulk click-to-call; it is one misclick away from a dialer.
• Caller ID and channel format. Some providers require a specific channel technology/prefix and a numeric caller ID. Keep these as config values per context, not string literals in the action.
• Debugging loop. Start with asterisk -rx "manager show connected", then read the package's Laravel log entry for the originate payload, then check dialplan show. That ordering separates auth problems from routing problems from application problems.
• Extension points to lean on. The published config (credentials, context, timeouts, number formatting), the action class (override getPhoneNumber()/getContext()-style methods if the package exposes them), and Filament notifications for user feedback. If the viewer's context handling doesn't fit your tenancy model, override the plugin's context resolver rather than forking the package.
• Document the dialplan dependency for the next developer. The single most useful thing you can add is a note in the repo: which Asterisk host, which context, which deploy step reloads it. That knowledge does not live in the package.