Search constraint location = Current page's Location returns 0, but data and IDs are provably correct

Need help
1

I have a repeating group of Menu Items that should filter by the page’s Location. The constraint returns 0 results even though every variable checks out. I’ve spent hours isolating this and ruled out the usual causes — details below.

Setup:

  • Page menu, Type of content = Location

  • Navigation to the page works: a button passes the Location via “Data to send”, and the URL contains the correct record

  • RG: Type of content = Menu Item, Data source = Search for Menu Items with constraint location = Current page's Location

  • location is a field on Menu Item, field type = Location (a reference to the Location data type, not text)

What works:

  • Search for Menu Items:count (no constraint) returns 8 — correct

  • A bare text element on the page set to Current page's Location's name shows the correct name

  • A bare text element set to Current page's Location's unique id shows the correct id: 1779789786297x986001693172420500

  • Opening a Menu Item in App data and following its location field leads to the Skt. Pauls Location record, whose unique id is the same id above — so the page’s Location and the items’ location field are provably the same record

What fails:

  • Search for Menu Items with constraint location = Current page's Location returns 0

  • Same result via :filtered with the equivalent condition

  • Rebuilding the constraint from scratch (selecting the field fresh) — still 0

Already ruled out:

  • Privacy: every field on Menu Item and Location has View checked, and “Find this in searches” is checked. Unconstrained search returning 8 confirms searchability.

  • Not previewing the page directly — I always navigate from the index page via the button, and the unique id confirms the right Location arrives.

  • Data is not pointing at a deleted/other Location — IDs match exactly.

Question: Why would a reference-field constraint (location = Current page's Location) return 0 when both sides resolve to the same record by unique id, the field type is correct, and privacy is open? Is there a known cause for a Location-type constraint silently not matching even when the unique ids are identical?

Happy to share screenshots of the data types, privacy rules, the RG data source, and the debugger.

3

Can you share screenshots of the RG/Conditions?

4

It looks to me like you have everything setup correctly.

It is possible that when you do your search for Menu Items where location=Current pages Location, that the data source of the page has not rendered yet. This would cause a search for Menu Items where location = “” which could result in zero records getting returned.

So maybe use a url parameter instead?

5

have u checked if you are ignoring empty constraints?

6

I think QinisoG might be onto something here.

If the IDs match, the unconstrained search works, but the constrained one returns nothing, I’d start looking at timing rather than the data itself.

I’ve run into cases where a page receives data through “Data to send” and the repeating group evaluates before the page’s thing is fully available. So the search ends up running against an empty Location, returns 0 results, and the RG stays empty. Then when you check the page manually a second later, everything looks correct because the data has already loaded.

A couple things I’d try:

  • Put the RG inside a group and set that group’s content to the page’s Location. Then reference the parent group’s Location in the RG search instead of the page directly.

  • Or add a condition so the RG only loads its data source when Current Page’s Location isn’t empty.

I’d also try the URL parameter approach that QinisoG mentioned. I’ve had cases where URL params were available immediately while the page thing took a moment to resolve.

Just a guess, but my money would be on some kind of loading/timing issue rather than the search constraints themselves. The fact that the unconstrained search works makes me think the search is fine and it’s just getting evaluated a little too early.