fix(history): keep unanswered legs so grouped calls stay complete

[tommaso-ascani]

Reference NethServer/dev#8105

The history queries dropped every NO ANSWER row that shared its uniqueid with an ANSWERED one, and kept at most one unanswered row per uniqueid+linkedid.

That hid the legs a call actually rang. A ring group dials all of its members from the same channel, so every leg shares one uniqueid and all but one were discarded here — which is why a ring-group call could never be expanded in the call history, while a queue call (whose attempts get their own uniqueid) could.

With call grouping those legs are the call's interactions: the middleware collapses them by linkedid into a single expandable row, so they have to reach it intact. Removed from both the personal and the switchboard query.

The extra rows are not shown as-is: the middleware groups them, and prunes the queue's own per-member bookkeeping legs (nethesis/nethcti-middleware#70).

Test Case

1. Create a ring group with at least two reachable members.
2. Call the group and answer from one member.
3. Open the CTI call history: the call is one row (destination = who answered) and expanding it lists every member that rang.
4. Repeat without answering: the row shows the group name, expanding it lists the members.
5. Check a queue call and a direct call are unchanged.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: bf39022d94

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[tommaso-ascani]

Code review

Found 2 issues:

1. Cross-repository impact not evaluated. These two queries back /historycall/interval and /histcallswitch/interval, which are consumed by more than the call-history page: nethlink fetches the same endpoint for its last-calls panel with a fixed limit=15 (src/shared/useNethVoiceAPI.ts), and so do the CTI drawers. Now that every leg is returned, that window fills with legs of the same call, so the desktop client shows the same call repeated and fewer distinct calls. Only the CTI history goes through the middleware that groups them by linkedid; every other consumer receives the raw legs. Per the workspace AGENTS.md ("Always evaluate cross-repository impact" / "When changing APIs: verify nethcti-middleware, verify nethcti-server, verify frontend/client compatibility"), the client side needs a decision before this merges.

nethcti-server/root/usr/lib/node/nethcti-server/plugins/dbconn/plugins/dbconn_history.js

Lines 634 to 646 in bf39022

	'(cnum IN (?) OR dst IN (?)) AND ' +
	'(calldate>=? AND calldate<=?) AND ' +
	'(cnum LIKE ? OR clid LIKE ? OR dst LIKE ? OR cnam LIKE ? OR dst_cnam LIKE ? OR ccompany LIKE ? OR dst_ccompany LIKE ?)' +
	// Unanswered legs are NOT filtered out any more. These two conditions used
	// to drop every "NO ANSWER" row that shared its uniqueid with an ANSWERED
	// one, and to keep at most one unanswered row per uniqueid+linkedid. A ring
	// group dials all its members from the SAME channel, so all its legs share
	// one uniqueid and all but one were discarded here. With call grouping those
	// legs are the call's interactions: the middleware collapses them by
	// linkedid into a single expandable row, so they must reach it intact.
	' AND NOT (lastapp = "Stasis" AND lastdata = "satellite")',
	data.endpoints, data.endpoints,
	data.from, data.to,

2. Only the "all directions" branch was changed, so the result now depends on the direction filter. The in, lost and internal branches still drop unanswered legs whose call was answered (linkedid NOT IN (SELECT uniqueid ... disposition = "ANSWERED" ...)). The same call is therefore expandable with no direction filter and not expandable with "Incoming", and a call answered elsewhere disappears entirely from that filter instead of being grouped.

nethcti-server/root/usr/lib/node/nethcti-server/plugins/dbconn/plugins/dbconn_history.js

Lines 607 to 612 in bf39022

	'(cnum LIKE ? OR clid LIKE ? OR dst LIKE ? OR dst_cnam LIKE ? OR dst_ccompany LIKE ?)' +
	'AND (disposition NOT IN ("NO ANSWER","BUSY","FAILED")' +
	'OR (disposition IN ("NO ANSWER","BUSY","FAILED")' +
	'AND linkedid NOT IN (SELECT uniqueid FROM cdr AS b WHERE disposition = "ANSWERED" AND b.uniqueid = cdr.linkedid)))' +
	' AND NOT (lastapp = "Stasis" AND lastdata = "satellite")',
	data.endpoints, data.endpoints,

nethcti-server/root/usr/lib/node/nethcti-server/plugins/dbconn/plugins/dbconn_history.js

Lines 845 to 849 in bf39022

	'(calldate>=? AND calldate<=?) AND ' +
	'(cnum LIKE ? OR clid LIKE ? OR dst LIKE ? OR cnam LIKE ? OR ccompany LIKE ? OR dst_cnam LIKE ? OR dst_ccompany LIKE ?) ' +
	'AND (disposition NOT IN ("NO ANSWER","BUSY","FAILED") OR (disposition IN ("NO ANSWER","BUSY","FAILED") AND linkedid NOT IN (SELECT uniqueid FROM cdr AS b WHERE disposition = "ANSWERED" AND b.uniqueid = cdr.linkedid)))' +
	' AND NOT (lastapp = "Stasis" AND lastdata = "satellite")',
	data.trunks, data.trunks,

[tommaso-ascani]

Correction to the review above

I measured issue 1 instead of reasoning about it, and it does not hold as written. Row counts over 60 days on the test PBX, before and after this change:

endpoint	before	after
/historycall/interval/user/201 (what NethLink calls)	45	46
/historycall/interval/user/202	29	32
/historycall/interval/user/203	36	36
/histcallswitch/interval	120	163

The two conditions only ever filtered NO ANSWER rows, and a personal history is mostly the user's own answered legs (24 of 28 rows in the sample). So NethLink sees between zero and three extra rows over two months, not a window full of duplicates.

The repetition its list already shows is pre-existing and unrelated: extension 201 gets 46 rows for 26 distinct calls now, and got 45 rows for the same 26 calls before. Those are multiple ANSWERED legs of one call, which neither condition ever touched.

Issue 2 (the direction filters still dropping legs, so the same call is expandable with no filter and not with "Incoming") stands as written.

[tommaso-ascani]

Issue 2 addressed in eea11a1: the incoming and internal branches now honour expandLegs too, so a call is expandable under every direction filter, not only with no filter.

The two lost branches deliberately keep the condition unconditionally — there it is not a deduplication but the definition of the filter (a lost call is one nobody answered), so dropping it would list answered calls as lost.

Issue 1 was already withdrawn above and is now moot: f74ba98 restored the deduplication by default, so every consumer other than the middleware receives exactly what it received before this PR.

[tommaso-ascani]

Follow-up on issue 2: making those clauses conditional was not enough, and I had picked the wrong clause. A grouped call still would not expand under any direction filter, for a different reason — the filters match leg by leg.

The switchboard incoming branch selects rows whose channel is a trunk (plus the attended-transfer special case); a queue call's member legs run over Local/<ext>@from-queue channels and match neither. Measured on one real queue call: 9 legs total, 4 returned by the incoming filter, and pruning the queue bookkeeping left a single row. The personal branches truncate the same way, matching only cnum/dst against the user's own endpoints.

Fixed in 58c70c7: under expandLegs the filter is applied by linkedid, so any matching leg brings back the whole call. Over 60 days on the test PBX that is 61 -> 122 rows, and faster than before (0.004s vs 0.018s) since linkedid is indexed. Verified working on the box with the Incoming filter.

Worth a second opinion on one consequence: in the personal view a call the user took part in now brings back the legs of the colleagues involved (who else the queue rang, who answered instead). That is what expanding a call is for and what NethServer/dev#7360 asks for, but it is a visibility change, and it is gated behind expandLegs so only the middleware gets it. Happy to restrict it to the switchboard query if you would rather keep the personal history to the user's own legs.