Forum Academy Marketplace Showcase Pricing Features

Filter a repeating group by a field that does not belong to the repeating group's type

Hi all,
I am trying to replicate a search box where the user can input a keyword and that results in a repeating group filtering for this keyword. It works very well except that I can’t have the user search for a field that does not belong to the repeating group’s type and that’s precisely the field that the user is most interested in filtering the repeating group for. Any clues ?

Here’s my data structure :
I have 2 data types: Invoice and Customer. There is a field within Invoice whose field type is Customer, i.e. it’s not a text. And i want to search for Name which is in the Customer data type.

I have a repeating group whose type of content is Invoices and which returns values from the Invoices data type plus Name, which is a field within the Customer type (which is related to the Invoices type):

Now, I want to be able to filter the repeating group for Name (which is a Customer type) based on the user’s input. In order to do that, I have an Input box and I added a constraint to my repeating group data source search that says “Any field contains input search value”. The search works very well for all fields, i.e. the repeating group is indeed filtered for whatever the user types in in the input box, but the repeating group is not filtered for Name because it belongs to a type that is different from the repeating group’s type.

I’ve tried to use the list shifter plugin from @keith to do that, but I’ve failed so far. Any help would be greatly appreciated.
Thank you!

@42.decaen You need to use :filtered for this.

The caveat is that the name will be case sensitive

Bubble tips

1 Like

Oh wow, thanks @sharma.himanshu0608. I was not aware of that option.
However, I see two potential drawbacks with that solution : (i) like you said, the search is case sensitive, which is not great from a UX perspective because the user might not find what they are looking for because of case mismatches and (ii) if I understand correctly, using “:filtered” will perform the filtering on the user front (vs. on the server) which might slow down the process.

I’ve also tried the Fuzzy Search plugin from ZeroQode but it does not allow to filter for a field that does not belong to the repeating group’s type. There must be a way to do what I’m looking to do in a UX / user friendly way, but I haven’t found it yet.

@42.decaen you could also save the customer’s name as a text field on the Invoice. This would require a tiny bit of maintenance in the event that a customer’s name is ever changed, but I don’t imagine that would happen much.

Another solution, probably overkill for this particular situation but I’ll throw it out there just in case you see value in it or you need to use a similar approach in the future:

  • Create 3 hidden repeating groups used to store variables.
  • The first RG you would set up just as the one in your screenshot, RG Invoices.
  • The second RG, lets call this RG Customers, would have a datatype of Customer and in the data source you would add the constraint “name = search input’s value”.
  • The third RG, lets call this RG Customer Invoices , would have a data type of Invoice and search constraint of “Customer is in RG Customers’ list of customers”
  • In the visible RG that is shown to the end user, simply set the data source as RG Invoices list of Invoices merged with RG Customer Invoices list of Invoices

Hey @AlexE ,
Thanks so much for your answer. I’m really interested in your solution with the 3 hidden groups
I did what you said, and here are the results (see screenshot below):
A/ Basically, it looks like the third RG called RG Customer Invoices does what I need! It is a (i) RG with an Invoices type and (ii) it is indeed filtering for Customer name based on the search input’s value. So I can make this third RG visible. Thank you!
B/ Now, I want to make sure I understand what you were trying to achieve with the “visible RG”, because it might help me overcome some other related challenges I’m facing. I tried to follow your instructions and in the screenshot below, you’ll see that the “visible RG” does not filter for the input search’s value. Any clues why?

thank you!!

@42.decaen here’s a bit more info about the solution I proposed and the purpose each RG serves:

RG Invoices - this RG is meant to create a list of invoices with any field (date, label, total price) matching the search input

RG Customers - this RG is meant to create a list of customers whose name matches the search input

RG Customer Invoices - lists all invoices from all users in RG Customers

My understanding is that you want end users to be able to search for invoices that match any field on the Invoice plus the customer name. This is why I suggested the 4th repeating group, the only one you’d show the end user, which would contain the combined results of the 1st and the 3rd RGs. I hope I’ve explained myself clearly and that makes sense!

Now, to answer your question about why the results aren’t showing up properly I need to see how you’ve set up RG Invoices and RG Visible. RG Invoices doesn’t seem to be filtering the RG based on the search input. Is it showing you a list of all the invoices in your database? If you feel comfortable it would be helpful if you can share a link to the editor so I can have a look directly.

Sorry for the late response @AlexE
Thank you for the explanations! They make sense.
Sure thing, here’s a link to the editor: Fuzzysearchsearch | Bubble Editor

@42.decaen the first RG was missing a search constraint. Have a look now and test it out. Also I found this from another thread written by @cmarchan and I think it may be useful when deciding how to set up your constraints:

My experience has been that “contains keyword(s)” returns:

  • whole words only
  • words in any order
  • case insensitive words

“Contains” requires:

  • partial words
  • words need be in precise order
  • case sensitive words

Also important to note is that the “any field contains” option works like “contains keyword(s)”. To illustrate this point I created a new invoice where the customer is Spoony and the label is “Pack of Spoons”. As an end user if I search for “pack” I’d probably expect to see this invoice along with all the Hewlett Packard invoices. Instead, the only match is the Spoony invoice for Pack of Spoons. This is because the search as it’s currently set up won’t match on partial words.

I don’t know exactly how your customers will be searching, but generally speaking I would probably create a text field on the invoice item to store any string related to the invoice that the user may search. For example, customer name and product description. I would store all this info in lowercase. then, when the end user types into the search input I’d convert that string into lowercase and then use that value in the search constraint with the “contains” operator. This way you get matches on partial words and it’s case insensitive.

1 Like

Hey @AlexE, this is awesome. What you did is exactly what I was looking to do. And the info you provided on “contains keyword(s)” vs. “Contains” is very helpful. This is actually something I was wondering. Also, the suggestion on how to allow for insensitive partial word searches is spot on. That type of search is certainly what the end user is expecting and I will implement what you suggest. Thank you again, you’ve helped me resolve challenges that I’ve had for a few days now, and also challenges that I did not know about but that I was going to have for sure :slight_smile:

1 Like

Hey @AlexE,
I wanted to share this other option from @keith below. Basically, instead of creating hidden repeating groups, he just merges searches. This might be easier for maintenance purposes. So in my case, I actually just need 2 RGs:
1 = RG Customers with the constraint “customer name = search input’s value”
2 = the only visible RG that does "search for invoices where invoice label contains input search’s value " merged with “Customer is in RG Customers’ list of customers”

I just thought I’d share with you in case this might be helpful.

1 Like

This topic was automatically closed after 70 days. New replies are no longer allowed.