Clickable Emergency Contacts + Profile Quick-Contact

Canadian Elite Volleyball Academy — Development Update • April 23, 2026

Clickable Emergency Contacts + Profile Quick-Contact

What & Why

Today the Emergency Contacts block on an athlete's profile (e.g. Charlie's "Shayne Kulbacki — parent") is purely informational — the card cannot be clicked, so a coach who needs to reach a parent has to copy the number into their phone manually. At the same time, the community profile page for that parent (and for people in general) doesn't expose contact info: there's no phone, email, or address shown, only name + role + bio. This task closes both gaps:

1. Make each emergency contact card a real link to the contact's community profile when we can match it to a registered person. 2. Add a "Contact" panel on the community profile that shows email / phone / address, each as a one-tap action ( / / open in maps), so a coach, coordinator, or family member can reach out instantly.

Done looks like

• On an athlete's profile, each Emergency Contact card looks tappable (hover/cursor affordance) and, when clicked, navigates to the matching person's community profile in the same tab. The matching is done server-side and returns either a personId or null; cards with no match remain visually identical but non-clickable (with an unobtrusive "Not registered" hint).
• The community profile page shows a new "Contact" card directly under the header (above "About"). When the viewed person has an email it shows a clickable email row that opens the user's mail client. When there's a phone it shows a clickable phone row that triggers . When there's a street address it shows the address as a link that opens Google Maps in a new tab. Empty fields are simply not rendered, and if all three are missing the card itself is hidden.
• Each contact row also has a small "Copy" icon button so the viewer can grab the value without opening another app (toast on copy).
• Visibility rules: the Contact card is shown to (a) the person themselves, (b) any superadmin / coordinator / coach role, (c) any user who has a link to the viewed person (parent/child/guardian either direction), and (d) any user listed as an emergency contact of an athlete that this viewed person belongs to (so a coach viewing a parent reached via Charlie's emergency contact card sees it). Everyone else sees the profile without the Contact card.
• No regressions in the existing edit/delete flows on the emergency-contacts list, in the community-profile tabs, or in the parent-viewer test that already covers the page.

Out of scope

• Sending the email / SMS through our own backend (we only deep-link to the OS handlers).
• A new directory search for "non-registered emergency contacts" — if a card can't be matched to a person, it stays a non-link.
• Editing contact info from the community profile (editing still happens through the existing Edit Full Profile flow).
• Address geocoding / map embed inside the card (we only link out).
• Mobile push or in-app messaging.

Steps

1. Backend match endpoint — Add a small endpoint that, given an athlete's personId, returns each emergency contact augmented with a . Resolution order: (a) rows where the viewed athlete is the child and the linked parent's name matches, (b) exact match on or against academy_people in the same domain (academy / standalone) as the viewed person, (c) fall back to null. Reuse the storage layer; do not query the DB from the route directly. 2. Clickable contact cards — Update the emergency-contacts render block on the athlete profile to fetch the augmented list and wrap each card in a link to when present. Cards with no match keep their current look plus a muted "Not in directory" badge. Preserve the existing edit / delete affordances and stop the link navigation when the user clicks one of those buttons. 3. Contact card on community profile — Add a new "Contact" section to the community profile page that renders email / phone / address rows with , , and Google Maps links plus per-row copy-to-clipboard buttons and toasts. Hide individual rows when empty and hide the entire card when all three are missing. Add proper test ids. 4. Visibility gating — Compute the "can see contact info" boolean on the server (so the data isn't shipped to unauthorised viewers) using the rules in Done looks like. The community-profile API response should either include the contact fields or omit them based on this gate. Update the frontend type accordingly so the Contact card simply checks for presence of the fields. 5. Tests — Extend the existing community-profile parent-viewer test to assert the Contact card appears for an authorised viewer and is hidden for an unauthorised one. Add a small unit test for the emergency-contact matcher covering the relationship-match, email-match, and no-match cases.

Relevant files

- - - - -

Canadian Elite Volleyball Academy
elitevolleyball.training