Crm Hangouts Call Bundle Laravel Package

Getting Started

What this bundle actually does (read this first). oro/crm-hangouts-call-bundle wires Google Hangouts into OroCRM record views. On a Contact/Account/Customer page, hovering an email address or phone number reveals a Hangouts call button next to the existing Send Email / Log Call actions. Clicking it opens a Hangouts invitation (or starts the call immediately for phone numbers); once the call connects, Oro opens a Log call dialog, and the call's date/time, called number/email, and duration are written back to the activity automatically.

So it is more than the "opens a URL" convenience action it used to be — but it is still browser-driven and Google-dependent: there is no SDK, no OAuth handshake in PHP, no telephony, no recording. Everything hinges on the user being signed into a Google account in that browser, and on Google's consumer calling service still existing.

Minimal install

composer require oro/crm-hangouts-call-bundle

Then register the bundle the way your Oro version expects:

• Classic registration: add new Oro\Bundle\HangoutsCallBundle\OroHangoutsCallBundle() to app/AppKernel.php::registerBundles().
• Auto-discovery: confirm Resources/config/oro/bundles.yml exists in the package, then run:

php app/console cache:clear
# or on newer versions
php bin/console cache:clear

On multi-app setups also run php app/console oro:platform:update — Oro caches actions.yml, route metadata and system configuration aggressively.

Prerequisites before you test anything

1. An active Google account, signed in in the same browser you use for Oro.
2. First-run Google permission grant (standard Google Apps consent screen).
3. If you intend to call non-US/Canada phone numbers, a funded Google Wallet balance — otherwise the call simply will not start.

Where to look first

1. System configuration (Resources/config/oro/system_configuration.yml / settings.yml) — the release notes say calling is "subject to system configuration"; find the toggle that enables the button for phones vs. emails.
2. Resources/config/oro/actions.yml — the action/button definition (entity scope, group, template, conditions).
3. Resources/views/ — the Twig that renders the inline button next to the email/phone field.
4. Resources/public/js/ (or a js_modules entry) — the hover behaviour and the handoff that opens the Log call dialog and posts duration back.
5. DependencyInjection/ + Resources/config/services.yml — the URL/link builder and the call-logging service.
6. Resources/config/oro/entity.yml and any Entity//Model/ classes if an activity type is registered.

First use case. Open a Contact with an email address and a phone number. Hover the email — a Hangouts button should appear beside Send Email / Log Call. Click it: if the recipient is online in Hangouts you get an invitation/live call; otherwise an invitation is emailed. Then hover the phone number and click: the call should start immediately (free for US/Canada), and the Log call dialog should open in Oro with duration auto-filled after you hang up. If no button appears, check the system config toggle, the record's field values, and the ACL (see Gotchas).

Implementation Patterns

1. The intended "click, talk, log" flow — now mostly built in. User opens a Contact → hovers email or phone → clicks Hangouts → talks → Oro's Log call dialog captures notes and, on hangup, writes date/time, number/email and duration into the timeline. This is the release-notes behaviour; do not rebuild it. Your job is configuration, not custom activity wiring (that changed from earlier versions).

2. Deciding email vs. phone as the primary path. They behave very differently and you should pick deliberately:

• Phone — call starts immediately; free for US/Canada; other countries bill against Google Wallet; duration tracking is meaningful.
• Email — only rings if the recipient is online in a Hangouts app, otherwise it's an emailed invitation that may never be accepted; "duration" for such a call is of limited value.

If your CRM is used for outbound sales outside North America, phone calling is effectively a paid feature and needs a policy + Wallet funding process, not just an install.

3. Scoping where the button appears. In actions.yml you can typically control entities / for_all_datatypes, group_name and button_options, and template. Example shape (verify against the bundle's actual file before copying):

operations:
  hangouts_call:
    label: oro.hangouts_call.action.label
    entities:
      - Oro\Bundle\ContactBundle\Entity\Contact
      - Oro\Bundle\SalesBundle\Entity\Lead
    routes:
      - oro_contact_view
      - oro_lead_view
    groups:
      - call
    template: OroHangoutsCallBundle:Call:button.html.twig

4. Conditional visibility. The button must not appear when the field it would use is empty, and arguably not when the user lacks a Google account. Prefer Oro conditions/preconditions (e.g. @not_empty on the email/phone field, or a custom condition service) over shipping a button that fails silently.

5. Reusing the link/logging services elsewhere. Inspect with php app/console debug:container | grep -i hangouts. Typical uses: add the action to a custom page, or drive it from a workflow step.

$url = $this->get('oro_hangouts_call.link_builder')
    ->buildForEmail($contact->getPrimaryEmail());
return $this->redirect($url);

6. Tuning the auto-logged activity. Since the Log call dialog and duration write-back are provided, extend rather than replace: decorate the service that persists the call activity to add subject prefixes, owner/team defaults, or to map it to your own call-activity type. Also check whether the dialog is skippable — some teams find a modal on every click intrusive and prefer logging via the standard activity widget.

7. Template/JS override for branding or UX. Copy Resources/views/.../button.html.twig (and the hover JS if you change markup) into your own bundle at the same path and give your bundle higher priority in Resources/config/oro/bundles.yml. Never edit vendor files.

8. Extension point: swap the provider. The cleanest modernization is to keep the inline hover UX and the Log call dialog, and replace the URL builder with one that emits Google Meet, Zoom or Teams links. Decorate the existing service with a compiler pass rather than forking the bundle.

9. Expectation-setting for stakeholders. "Hangouts integration" now legitimately means CRM-tracked calls — but only when Google's service cooperates. Document that a failed Google login, an offline recipient (email path) or an empty Google Wallet means no call and no activity.

Gotchas and Tips

• Google Hangouts consumer service was shut down in 2022 in favour of Google Chat/Meet. This is the single biggest risk: the URLs and the invitation flow described in the release notes may no longer work as written. Test the exact end-to-end flow — including whether duration is still reported back — before committing. In many cases replacing the link builder with Meet is cheaper than adopting this bundle.
• The call is only as good as the browser session. No PHP-side OAuth means the user must already be signed into Google in that browser, plus the one-time consent grant. Users on shared/kiosk machines or hardened browser profiles will hit a login wall mid-flow.
• Money is involved for non-US/Canada numbers. Calls to other countries bill against Google Wallet; an insufficient balance means the call silently does not start. This is a finance/ops dependency, not a code one — decide who owns topping up the balance, and warn users rather than letting them click into a dead call.
• Email "calls" are not really calls. If the recipient is offline you've sent an invitation that may never be accepted. Do not treat email-path activities as completed calls in reporting.
• Verify platform compatibility before adoption. The feature set described (Log call dialog, automatic duration write-back) depends on Oro's activity manager and specific platform versions; the package's Symfony/Oro dependency constraints are the usual blocker. Run composer why-not / read the composer.json requirements first, and pin the version that matches your Oro release.
• Action metadata and system config are cached hard. After editing actions.yml or the settings, clear dev and prod cache; run the platform update command if routes changed. "My change didn't apply" is almost always stale cache.
• ACL is separate from visibility. A button can render for a user who cannot view the underlying record data (or the reverse). Check the action's permission settings if you need role-based visibility, and combine with the system config toggle — two switches must both be right.
• Bundle priority matters for template overrides. If your override isn't winning, it's load order in bundles.yml / AppKernel.
• No tests, low maintenance surface. Don't build critical workflows on it without vendoring/forking into your own namespace; keep the fork minimal and document the patch.
• Debugging checklist: grep -R hangouts vendor/oro/crm-hangouts-call-bundle, debug:container | grep -i hangouts, browser console for the hover JS and the Hangouts window, var/logs/ for Twig/action errors, and confirm the entity's email/phone field names match what the template and link builder expect.