Hi Tony -

I’ve encountered this problem before but haven’t had a chance to isolate yet what triggers the root cause.  Ran in to it again yesterday so plan on trying to isolate the steps soon.

In your case, the problem is that the search field ‘OwnerId’ is marked to query=“true” with an operator of “=”.  Change the query value to “false” (aka. Don’t search) and it should resolve your issue.

I think that when you add reference fields to the list of fields to search, Skuid is setting this to “true” and operator to equals (equals is the only option skuid allows on ‘Id’ fields).  

Again, just haven’t had time to diagnose yet but changing the attribute should resolve your issue.

Skuid Team - Any thoughts on this? In short, when a reference field itself is in the search fields, if it is marked to be “searched” with operator equals, in some cases, the client side code “aborts/errors” and no query is ever sent to the server - No error message, no exception and no network traffic.  I’ve seen where it does make the network call and other situations were it does not.  I’ll try to isolate the scenario where it doesn’t actually make the call.  Technically, when it does make the call, it’s following the search logic checking for ‘Id’ fields that ‘equal’ the input value.  Possibly the default when adding a reference field in search fields should be ‘don’t search’ - would be a rare circumstance where someone would actually want to search by the Record Id itself?

Hi Barry. Thanks for the suggestion. I tried that and it did not work in my test case but did seem to help somewhat in my actual application.

In the test case I am still getting the same behavior despite trying:

                          <searchfield query="false" return="true" show="true" field="OwnerId" operator="="/>

                          <searchfield query="true" return="true" show="false" field="Owner.Name" operator="contains"/>

                          <searchfield query="true" return="true" show="true" field="Name" operator="contains"/>

and

                          <searchfield query="true" return="true" show="true" field="Owner.Name" operator="contains"/>

                          <searchfield query="true" return="true" show="true" field="Name" operator="contains"/>

In my actual application I have it working properly when you click the magnifying glass but when you search directly in the box the wheel spins forever and the SOQL query is still mangled:

SELECT Appointment_Setter__c,Appointment_Setter__r.Name,Appointment_Setter_Name__c,Name,District_Org__c,District_Org__r.Name,District_Org__r.Current_Legislator__c,District_Org__r.Current_Legislator__r.Name,Id FROM Appointment_Setter_Request__c WHERE ((Lobby_Event__c = ‘a08d00000157NwQAAU’)AND((Staff_Status__c = ‘Approved’)OR(Staff_will_set__c = true)))AND(((Name LIKE ‘%test%’)OR(Name LIKE ‘%test%’)))

Note the two (Name LIKE ‘%test%’)

If I click the magnifying glass and get the pop-up my SOQL looks like this which work properly:

SELECT Appointment_Setter__c,Appointment_Setter__r.Name,Appointment_Setter_Name__c,Name,District_Org__c,District_Org__r.Name,District_Org__r.Current_Legislator__c,District_Org__r.Current_Legislator__r.Name,Id FROM Appointment_Setter_Request__c WHERE ((Lobby_Event__c = ‘a08d00000157NwQAAU’)AND((Staff_Status__c = ‘Approved’)OR(Staff_will_set__c = true)))AND(((Appointment_Setter__r.Name LIKE ‘%test%’)OR(District_Org__r.Name LIKE ‘%test%’)OR(District_Org__r.Current_Legislator__r.Name LIKE ‘%test%’)))

The XML for this situation is:

Anyone else experience this odd behavior?

Hi Tony -

I just noticed one more thing.

Can you add the field Account.Owner.Name to the Contact model on your page and let me know if that resolves the issue please?

Thanks!

Barry you are brilliant!  That fixed the problem both in the test case and in my application.

So the moral of the story seems to be that you need any search fields to also be fields that are part of the model that the reference is on, not just on the model being used for the search field lookup.

The other part about setting OwnerId search field to false does not seem to matter.

Thanks so much for your help!

Hi Tony -

Glad that worked for you!

Regarding putting the field in the model itself, yes, this is always something you need to have in-place.  The reason for this is two-fold:

1) When the page loads, skuid will query for all fields in the model.  Since you have your “display template” set to include the Owner.Name from the account, you will want to make sure that your Contact model has that field in there.  Otherwise, it will show up blank for existing data.

2) As you’ve encountered, during “search” processing, if the field is not in the model, it will ignore the search condition (I believe - I still need to play with this some more to truly verify)

Regarding the OwnerId field, in general, there typically wouldn’t be a need to add this field itself in to the search fields but rather add Owner.Name.  However, if the reference field itself does get added, best to mark it as “Don’t search” since Skuid will always apply an equals operator to that field.  

In short, any time you have a field in “Search FIelds” always make sure it is also in the target model (Contact in your case).  Additionally, if you are using “Option Source” of “Model”, the field also needs to be in that model.  There are some optimizations you can do here but as a general rule, if you follow this approach, you should be good

Skuid Team - I’m going to continue to try to isolate the situation where the query doesn’t even get sent to the server and will post a separate issue if I’m able to isolate.  Also, still might want to consider handling adding reference fields to search fields since I think most people will add the reference field itself, not the “Name” field which results in the query applying an equals to the “Id” field which is almost never what the page developer actually wants.