Sub-queue inheritance - blank columns

MS1Corp

I have a global queue that presents CustomFormA::FieldA1 and CustomFormB:FieldB1
Both field values are visible as expected.

I have a global sub-queue that presents identical columns, inherited from the parent queue

A1 value inaccurately presented as blank on the sub queue
B1 value accurately presented and visible on the sub queue

I modified the queue to present A4 instead of A1. Same result: A4 blank on sub queue.
Known problem? How do I fix the join, etc?

Worth noting, the Filter on the sub-queue is NOT related to A1.
Note: GitHub Issue #5890 (open bug) not the same as what I'm seeing.

Thanks

KevinTheJedi

MS1Corp

Can you show what you mean with all the criteria, columns, etc. shown from the queue modification page (in the admin panel)?

Cheers.

MS1Corp

Turns out it was essentially the same problem as #5890.

I was able to patch both the normal join strategy of a non-filtered column sourced from a custom form on a subqueue, AND the corresponding sub-queue Counts query.

Working properly now.
When's the 2.0 anticipated? Need a beta customer?

KevinTheJedi

MS1Corp

Again, can you show what you mean so the class can learn?

You can sign up for notifications on the Next site. We will send out campaigns for beta testers, etc.

Cheers.

MS1Corp

I can't provide a screenshot, but I'll try to describe again

Parent Queue
Col 0: Ticket Number (ootb field)
Col 1: Custom Form A, Field A1 (joined)
Col 2: Custom Form B, Field B1 (joined)
Example Data:
Col0 Col1 Col2
123 XXX YYY
presented on screen correctly

Sub Queue
Inherit Columns from Parent Queue
Filter on Form B, Field B1 "has a value" or any condition
Col 0: Ticket Number (same as above)
Col 1: Custom Form A, Field A1 (same as above, but system didn't create in independent Form A Join to fetch)
Col 2: Custom Form B, Field B1 (same as above, system created a Form B join properly)
Example Data:
Col0 Col1 Col2
123 ___ YYY
presented incorrect, Col1 is blank because system didn't join to Form A.

If the Filter is on a joined Form, that join is created and the field is presented.
All other non-Filtered joined Forms display as blank (no additional joins are created)

KevinTheJedi

MS1Corp

Yea but you said you patched it so care to share? Because I get most of what you're saying except the last bit. Are you saying if you filter on say Form A alone the proper JOIN is created in the query but if you add an additional form say Form B then only one will work and all others will be blank?

Cheers.

MS1Corp

if you filter on say Form A alone the proper JOIN is created in the query but if you add an additional form say Form B then only one will work and all others will be blank?

Correct.

I'm hesitant to share the patch until I put some meaningful test cycles in production first. I'll circle back. Thats why I was asking how long until 2.0. 😃

KevinTheJedi

MS1Corp

Odd.. once I see the changes you made I'll be able to better understand the problem and solution.

Cheers.

MS1Corp

Following up on this thread — we've now had meaningful production time on the patch (since April 14) and can share the details. Also flagging a regression in 1.18.4 that reverted (overwrote) our fix.

Root Cause (confirmed)

When a sub-queue filter references a field from Form B, the ORM builds a single shared tpwk_form_entry JOIN (A3) anchoring both form_entry_values joins. A ticket has one form_entry row per attached form, so A3 can only resolve to one form's row at a time. When A3 resolves to a Form B row, Form A values (joined through the same A3) come back NULL and the WHERE filter eliminates those rows entirely. Result: Form A columns always blank on filtered sub-queues.

The Fix — 4 changes to class.queue.php

Change 1 — getOrmPath(): Fork a separate entries!{fieldId} JOIN per field_id, each with the field's form_id added to the JOIN ON clause. Each field resolves independently through its own form_entry row.

Change 2 — mangleQuerySet(): Save $originalName before getOrmPath() rewrites it to the forked path, so the searchable fields lookup (keyed by original name) still succeeds. Normalize the annotation key back to entries__ path so renderBasicValue() can find the value.

Change 3 — QueueColumn::addToQuery(): Annotate using the normalized entries__ key (not the forked entries!N key) so renderBasicValue() can look up the value by original name from the result row.

Change 4 — QueueColumnAnnotation::addToQuery(): Same key normalization applied to the annotation class's addToQuery.

1.18.4 Regression

osTicket 1.18.4 (released June 17, deployed July 6 via auto-update) overwrote our patched class.queue.php. The 1.18.4 version simplified getOrmPath() back to a single shared JOIN ($meta = $root::getMeta()->getByPath($path[1])) — reverting the fix. Additionally, QueueColumnAnnotation::addToQuery() was refactored to a static method in 1.18.4, which conflicted with our Change 4.

We've re-applied Changes 1–3 on top of the 1.18.4 base (skipping Change 4 since the static method in 1.18.4 handles built-in annotations, not custom field paths). Working correctly again.

Happy to share the specific code blocks if that helps get this into the core. The fix is ₃₀ lines across the three locations. The forked JOIN approach also significantly reduces the row scan on the queue counts query (we saw 1.7M rows examined before the fix on a modest dataset).