Page MenuHomePhabricator

make acoustic mail data searchable through search kit
Closed, ResolvedPublic

Event Timeline

I'm trying to test this under the Mailing Datas test searchkit and not seeing any results come up when query for 3 mailing_identifiers that were sent out around October - November

OK - I see the error

Error: Call to a member function getEntityFields() on null in Civi\Api4\Query\Api4SelectQuery->autoJoinFK() (line 970 of /srv/org.wikimedia.civicrm/civicrm/Civi/Api4/Query/Api4SelectQuery.php).

I'll dig into that

Change 701330 had a related patch set uploaded (by Eileen; author: Eileen):

[wikimedia/fundraising/crm/civicrm@master] Add handling for extension tables without id

Change 701330 merged by jenkins-bot:

[wikimedia/fundraising/crm/civicrm@master] Add handling for extension tables without id

@EYener I deployed a change to staging and to live that addressed the issue you identified. I need to do some more work on upstreaming but for now it should be working

@Eileenmcnaughton thanks! This is working in dev but not in prod. Here is the same searchkit reproduced in prod. I'm getting a spinning wheel when I click on 'search' and the results are unexpected: CIDs as old as 1 are showing up in the initial results, which never fully return.

@EYener I just made the same update to that search that I did on live - see

image.png (288×772 px, 32 KB)

By having an optional (LEFT) join & no WHERE clause you are not filtering the returned results at all. This is a bit of a confusion that people hit in the UI - the join criteria are the ON clause and not where - which is on the right

image.png (390×1 px, 52 KB)

I should note this is a tricky UI issue - to improve usablity without losing the power of the engine - if you have any good ideas we can feed them back upstream

Change 703261 had a related patch set uploaded (by Eileen; author: Eileen):

[wikimedia/fundraising/crm@master] Update generated code for omnimail

I have worked with Coleman to get a version of the patch I worked on (actually not really a version - something completely different he wrote :-) - and hence the upstreaming part is sorted.

I am putting this into review because there is an update to the generated code which we should merge before the next update when we adopt Coleman's patch

Sorry @Eileenmcnaughton I'm coming back to this now; is the query in prod in the correct format, or was the patch to make the UI more SQL-like, or something different...? Thanks for the help! Either way, it's working now.

@EYener this should be correct now - we just need to merge & then we can close it

But also, be careful to specify that the join is 'Required' when joining on this table

Change 703261 abandoned by Eileen:

[wikimedia/fundraising/crm@master] Update generated code for omnimail


this seems to duplicate what was merged