Unfortunately, that post ended with no clear resolution. Even though the conclusion of that post was that even though the inspector was returning null values for “this thing” in the advanced filter, they claimed it was returning a value.
However, I have run into a dead end here and can’t get it to work properly.
I have a dropdown box that has three possible values: empty (null), Yes, No. I have a field called Submitted On (a date field) that I want to see is empty or not. I want the following logic to take place:
If the dropdown is empty, show all results
If the dropdown is yes, only show non-empty results
If the dropdown is no, only show empty results
I had a similar logic with a checkbox that worked with a similar advanced search, but it only showed all results or non empty results. Logic here:
Right now, it only shows me all results, or empty results. Choosing Non-empty results in an empty search ironically. There are values for that field in various objects, so it should be showing (as it does when I use a checkbox logic).
I’m guessing maybe my and/or logic could be the issue, but I’m not sure.
I read over the earlier post, and it’s not clear that this is the same issue. But it doesn’t seem like you need to use an advanced filter.
If I understand your intent correctly, you have a repeating group that you want to display a list of things (invoices?). You are trying to use a dropdown to filter that list based off of 3 options (yes, no, empty). Is this correct?
I can think of two options:
One, you could create an additional data field that evaluates to a yes/no. (lets call that submitted yn). then add a workflow that changes this yes/no based on whether or not the entry has a submitted date in the date field.
In this case, you have to make sure that your dropdown “choices style”: Dynamic and “Type of Choices”: “yes/no” in your properties panel. See below:
Next, you want to apply the filter to your repeating group. Your data source will be “do a search for… Filtered” and your filter will be Submitted yn = Dropdown yes/no’s value.
Alternatively, you can use custom states for your RG. then set up a workflow based off the dropdown. It will be something like “when dropdown’s value is changed” set state. Then your state will be a filtered list of invoices. here you can use the “only when” feature on the workflow to dictate which filter gets applied. meaning, you would create to workflows for when the dropdown gets changed, one to only apply when the dropdown is “yes” and one to only apply when dropdown is “no”
There are a fair amount of videos on this but here is one: https://www.youtube.com/watch?v=cEcmRYVBCnc
Hey Daniel, that would be easy to add an extra field in that invoice data type. I guess I still need to have a better understanding of what would be more efficient: adding another field to a data type (that is somewhat redundant by easier to access) or doing filtering/advanced searching.
Regarding the advanced search, I’m still confused why that wouldn’t work. Any ideas?
I’ve had a lot of trouble getting advanced filters to work. I don’t always understand the language logic enough to know why it doesn’t work. maybe it can. if so, then you probably just haven’t got the programming language right. Im no expert, but you can definitely do what you want using custom states. I’ve had to learn how to use custom states to stack filters on repeating groups and it’s pretty useful.
Hi guys, i just want you let know that my issue is still processed with bubble support with no clear ETA of resolution. So my advice is to avoid advance filters in such cases
Try enabling the expression parenthesis in experimental features and check back to see if your expression is how you want it to be.
I assume you have this expression in a repeating group data source yes?
As mentioned by @danielhester you can store the search results in a state and then point your RG’s data source to that state with a filter. Is it a better way? Yes, having a Search as an RG data source (:filtered or not) is going to incur a realtime search WU cost that is exponential to it’s constraint’s returned data size.
I’m using a repeating group hidden in a popup to store searches, and then accessing them when needed in another repeating group, and filtering as needed.
I did have the question of whether doing a new search with constraints is less efficient than using a stored search and then filtering it with the constraints, but it seems you just confirmed that. I also wonder if there is a difference in performance between storing a search and accessing it from a custom state vs a hidden repeating group.
As mentioned in my post having a Search as your data source in an RG will make it a realtime search and you pay for it in WU. This is regardless if it’s hidden or not.
Having it hidden can be used to delay when that data gets called but there’s a caveat; if that hidden RG gets referred to by another element during page load, the data source still gets loaded regardless.
Storing lists in a state is different. Values in states are always static. You have to define values in states through workflows. This makes any Searchs become static values in states and hence don’t incur any realtime search WU costs.
I haven’t noticed any big difference in speed storing lists in an RG versus state though. On the other hand i have noticed it to be a little faster to load a search first then filter it after but it could just be my own bias.
I’m a little confused by your response. From my understanding, we have to do a search to find data in the database, so whether it is stored in a repeating group or a custom state, a search is going to need to be made to populate that list, correct? If so, I would imagine it would be just about the same performance hit regardless.
It’s when we talk about how to manipulate the data where I thought we can make performance improvements by storing a temporary list on a custom state or a hidden repeating group. The idea being that there would be one search done on page load, and then afterwards we are just doing filtering, sorting, etc. of that list, instead of doing another search on that same list with different constraints, sort, etc.
I’m glad you made that distinction that a custom state list is static, whereas a repeating group would be dynamic, as in my case I do need the list to be dynamic. A follow up question here is then does another search get incurred every time we sort or filter that visible RG, which is referencing the hidden RG that does the actual search? From what I can tell it does not appear that way, but it doesn’t hurt to ask.
Another question about a similar strategy with using conditionals. If I was to use conditionals to do different types of sorting or filtering, how does that work performance wise? Do the different filtering results get calculated when that element is displayed, or does it wait until that condition is met before filtering?
