- Ambiguous lookups (2+ contacts on one email) now dedupe by Contact Id
and fetch each candidate's full record so the picker shows
name + account + email instead of just the bare search payload.
- Per-row "תייק" button on each linked case lets the user pick the
correct case to file to when a contact has multiple cases; bottom
"תייק לתיק הזה" button is hidden in that scenario.
- "→ חזור לרשימת אנשי קשר" link restores the candidate list after
drilling into one of them.
- Contact name + case rows in the sidebar are now hyperlinks that
open the entity in Klear.
- AddInHost.LaunchFileToCaseAsync accepts an optional MatchResult and
auto-files when the sidebar resolved a single linked case, skipping
the manual search dialog.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two quality-of-life tweaks on the sidebar:
1. New CaseStatusToHebrewConverter translates standard EspoCRM Case
statuses (New / Assigned / Pending / Closed / Rejected / Duplicate /
In Progress / On Hold / Resolved / Cancelled / Closed Won / Closed
Lost / Open) to Hebrew. Unknown values pass through unchanged so
custom statuses configured per-tenant still render.
Wired in ReadingPaneView.xaml via Status binding.
2. MatchingService now pulls up to 50 cases per contact instead of 5.
The sidebar's ScrollViewer already handles long lists. 50 is well
below EspoCRM's default page size and large enough for any realistic
attorney/contact relationship. Section header changed from
"תיקים אחרונים" to "תיקים מקושרים" to reflect that it's the
complete list, not just the most recent.
Tests: 39 passing.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The sidebar lookup was raising
System.Text.Json.JsonException: The JSON value could not be converted
to MarcusLaw.OutlookAddin.Core.Models.SearchResult
because EspoCRM's /EmailAddress/search endpoint returns
[{id, entityType, emailAddress, name}, ...] (and on some hosted builds
{entityId, entityName, ...}), not the GlobalSearch-style envelope.
- IEspoCrmClient.EmailAddressSearchAsync now returns
Task<List<EmailAddressMatch>>.
- EspoCrmClient parses the bare array, with a fallback that tolerates
{"list":[...]} wrapping if some plugin reshapes the response.
- EmailAddressMatch accepts both the {id, entityType} and the newer
{entityId, entityName} field naming.
- MatchingService updated for the new contract.
The GlobalSearch endpoint (FileToCaseDialog search) still uses the
{total, list} envelope and is untouched.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
PointStar