RG wtih Grouping, nested repeating group to display group's relevant records - but the 'empty' value group's nested RG always shows 0 records

[mkenton1]

I came across a bug in my setup of making an RG with a datasource “grouping” based on a field (“Location”) on my data type (“Item”)… where I want to display (in a nested RG) all the items that belong in each grouped Location.

I see the question a lot about how to get those results, but of course the answer is that you nest a second RG in the Grouping RG’s cell, where you search/filter for the datatype, with constraint: field = parent cell grouping's (field you grouped by). I’m using a selected list of Items in a custom state, so I’m using the “filtered:” operator on that working custom state list of all the Items being grouped.

Main RG

Nested RG (Items per Grouping)

And that typically works, however in my use case, I often have some items where the field being grouped by is empty. The grouping data sourced RG does yield this empty group correctly.. but the nested RG always pull 0 srecords for that search/filter constraint.

In this example, I’m pulling in 23 records with location = empty, yet 0 match the filter
Note, the text “–No Location-” is not a record, it’s literally the (empty) location’s Name field,just with a conditional to display that text there when Parent Group's Grouping's Location is empty

It might be a bug, or maybe an inherent restriction of searches based on grouping’s returned field…. or maybe there’s some nuanced but obviously wrong config I did, but I don’t think so. So I’m here to share what worked. And bonus, it’s NOT creating a dummy group with duplicate formatting outside the RG to handle a separate case.

Furthermore, using “ignore empty constraints” on the nested RG source is not correct, because it will pull ALL results in for the case of the empty group (not actually just the records where the field is empty).

Note the 65 total record in this form being grouped into their respective sections, yet despite the populated ones appearing in their appropriate groups above, the empty one now receives all 65. (and yes, all 65 appear in my displayed item titles below the image, when in fact there are only 23 items with empty locations that should appear in this group)

SO FOR THE SOLUTION!

Luckily it’s a very quick fix. Use the “advanced:” filter as such.

It seems like the exact same condition as the non-advanced filter constraint, but nope. Voila, I get my correct 23 results to display in the empty group with the simple switch. And the data in the other groups remains correct.

If you are doing a “Search for” on your nested RG data source (rather than my custom state list with :filtered), then you won’t have access to the “Advanced” filter. I don’t know if this problem even arises in that case. But if it idoes, perhaps you can append the :filtered operator at the end of a proper “ Search for X” expression in the RG data source.

[J805]

Glad you were able to figure out a solution.

Personally, I never recommend using ‘Advanced’ filtering. Others might feel differently. This will be extremely heavy on your workload. Especially as the data increases in your app. Instead, maybe consider restructuring your database architecture.

Could you make a default location? Like a location that says - No Location - and then it will just show that for those that don’t have a location.

If your field is an address field, then you can potentially add another field to that DataType with a text field, potentially. It really just depends on how you have things set up.

Hope that helps a bit.

[mkenton1]

I believe there’s some overgeneralized concerned about :advanced filter. It does depend on context.

Yet I certainly respect you mentioning it because of my use in a nest RG - that can be a huge red flag for failiure to optimize when a restructure is needed.

However, for my use case, this is simply a popup form that loads a few items on the rare occasion that peopel want to make batch changes. It’s not something to wait for on page load, and it’s still lightning fast in this use case - certainly not worth restructuring the DB for in this feature.

As far as the recommendation to make a “no location” filter - I’ve done this in some cases and I’ve often come across many downsides. I think the issues I’ve seen can be somewhat mitigated by database triggers, and some other strict adherence to workflows.

But in my case, I have many users across many projects who create their own “locations” and manage, rename, delete, etc. So I’d need to do things like “upon creating a project, create a new location called “—No Location-” and then have some additional logic to make it not editable or deletable.”

And ideally to always appear up at the top of dropdown lists, which probably involves some JS additions (or I guess locations could get a ‘order’ field, and then always assign it order # 1 and sort by that field. And all teh additional logic for “remove location” to, instead of clearing the field, switch it to that particular record of that particular project.

It’s just a lot of extra work and loses some of the functionality of being truly an empty field (for all the conditional logic that uses things such as “when location is empty” - which is much harder to refactor to handle at the app level to instead look for ‘when location is the particular default empty one associated with this user’s project. And it needs to be per-project and identified correctly, because I do a lot of grouping/filtering based on these fields - and if I were to ever pull the wrong project’s “empty” field, It would fail or (if really poorly done without security rules), pull in records from someone else’s empty location record!

[J805]

Make sense to me.