No compliance report attached to communication #158

New issue

Closed

opened 2026-07-22 22:56:17 +00:00 by eliribble · 1 comment

eliribble commented

2026-07-22 22:56:17 +00:00

Owner

I just tested the compliance flow from RMO in staging. I created a report with an address within the Delta boundary. I included comments on the report. The report flow looked fine, no errors. I did not include a reporter name, email address, or phone number as part of the report. After submission, a communication object did correctly show up in the sync.nidus.cloud UI. However, it was missing any related reports. There should have been one related report, even though it was fully anonymous, since it included a location and basic information.

I think this was broken recently as part of the fix for #149. Please take a look.

ned was assigned by eliribble

2026-07-22 22:56:17 +00:00

ned referenced this issue from a pull request that will close it,

2026-07-22 22:58:43 +00:00

fix: remove over-aggressive phone filter from related records matching #159

ned commented

2026-07-22 22:58:49 +00:00

Member

Confirmed — this was broken by the fix for #149. The root cause is in CommunicationRelatedRecords.

How it broke

The fix for #149 (PR #151) added an addMatchingReport helper function with a blanket filter:

addMatchingReport := func(r modelpublicreport.Report) {
    if r.ReporterPhone == "" {
        return // Don't relate records across empty phone numbers
    }
    ...
}

This filter was applied to ALL matching paths — both name-based and address-based. When an anonymous compliance report (no reporter name/email/phone) is submitted via RMO, CommunicationRelatedRecords enters the address path, finds other reports at the same address, but then filters every one of them out because they all have empty ReporterPhone.

Why it's wrong

The phone filter was meant to prevent over-matching in the #149 scenario, but the actual fixes for that issue were:

isCompleteAddress() on the address path — ensures the address has real GID or full components before matching
Early-return in publicReportUpdateAddressID when both GID and Raw are empty — prevents grabbing whatever random address with gid=''

Both of these are sufficient guards. The blanket phone filter is unnecessary and actively breaks legitimate address-based matching for anonymous reports.

Fix

PR #159 removes the ReporterPhone == "" check from addMatchingReport. The dedup logic is preserved. Address-based matching now correctly relates anonymous reports that share a complete address.

#159

Confirmed — this was broken by the fix for #149. The root cause is in `CommunicationRelatedRecords`. ## How it broke The fix for #149 (PR #151) added an `addMatchingReport` helper function with a blanket filter: ```go addMatchingReport := func(r modelpublicreport.Report) { if r.ReporterPhone == "" { return // Don't relate records across empty phone numbers } ... } ``` This filter was applied to ALL matching paths — both name-based and address-based. When an anonymous compliance report (no reporter name/email/phone) is submitted via RMO, `CommunicationRelatedRecords` enters the address path, finds other reports at the same address, but then filters every one of them out because they all have empty `ReporterPhone`. ## Why it's wrong The phone filter was meant to prevent over-matching in the #149 scenario, but the actual fixes for that issue were: 1. `isCompleteAddress()` on the address path — ensures the address has real GID or full components before matching 2. Early-return in `publicReportUpdateAddressID` when both GID and Raw are empty — prevents grabbing whatever random address with gid='' Both of these are sufficient guards. The blanket phone filter is unnecessary and actively breaks legitimate address-based matching for anonymous reports. ## Fix PR #159 removes the `ReporterPhone == ""` check from `addMatchingReport`. The dedup logic is preserved. Address-based matching now correctly relates anonymous reports that share a complete address. https://source.gleipnir.technology/Gleipnir/nidus-sync/pulls/159

eliribble closed this issue

2026-07-22 23:08:24 +00:00