Repeating group data not showing on first login

I decided to turn my app native with BDK which has some pre-requisites. One of which is that everything is on a single page. So, I moved the sign up form from the index page into a group which is shown and hidden accordingly. Testing is being done in the BDK native app but the issue is the same in a normal browser.

During testing, I found that if a user is already logged in when the app starts up, everything is ok. A RG of users based on some filters is loaded and displayed. All good.

However, if the user has just signed up or logged in, then the group shows up but without populating the RG.

Opening up the app when already logged in:

Now I log out of the app, shut the app down and relaunch.

For testing, I added a popup to display the currently logged in users details before making the group visible, just to make sure there was an actual user available for the filters to work on.

Which verifies a user is logged in:

But then when I dismiss the popup, i’m presented with:

If I go and change the search parameters (from within the app), like modify the age range i’m interested in, then the RG is populated.

I’ve tried about 10 different things which I didn’t document (lesson learned) but only one worked but I couldn’t reproduce it without messing things up.

The one that worked was to open up a distance slider popup which has autobinding to the current user. Without changing anything on the slider, closing it reveals a populated RG. However I was unable to reproduce this by using states in the background without affecting the UI.

Everything else i’ve tried has failed but all are based around Page loaded (entirely), scheduling custom workflows, using popups for the login and having the page open in the background from the start… I tried pre-populating a state with the first 10 results and using that as a data source. Nothing.

Assuming this was being caused by the group being hidden, I made sure it was visible on page load but still nothing.

I found this thread but fail to see how to apply his solution:

Hey, you could send another workflow ‘Display Data’ to the RG after login or signup, then it should reload the content.

That sounded like it should do the trick, apart from I did a Display List in Repeating Group.

I tried this in User Logged In work flow and When Page is Loaded (completely) and both result in:

In what instance would a database return no results other than it being empty (which it definitely isn’t)

Privacy settings.
If the user doesn’t have the rights to access data, it will return 0.

Oh yes. But that’s not it :frowning:


My hunches / questions I would ask myself:

  • Is that display data step buggy? Why do you even need it a step?
    • Can I delete that step,
    • set the RG to display the search
    • limit the visibility by constraining it in the privacy rules?
  • Could List Shifter solve this? List Shifter has solved tons of problems for me in the past, why not this one?
  • Is there something to do with order of operation?
  • What would Petter do?

Thanks for the mention @rico.trevisan :slight_smile:

It’s a bit difficult to debug without knowing the data source you’re using on the Repeating Group. Any chance you could share the editor or a test page?

I did some quick testing on this page (probably not correctly reflecting your scenario…), and the RG updates with the UID of the user when logging in. The button here just logs in with pre-filled info, so feel free to test it.

As a general note I’d encourage you to try to find solutions that don’t rely on workflows to populate list data, to keep it dynamic.

1 Like

I just finished reading your book. I’m a little bummed I didn’t find it before I set off on my epic journey. Really useful stuff. I’ll be examining my build with a fine tooth comb and fresh eyes. I’m going to see if I spread the process to before its needed. In the meantime, you should be able to see my code here I’ve not shared my code before so if its not right let me know and i’ll make the necessary changes.

Some quick thoughts here:

Bubble conditions follow the same left-to-right logic that Bubble expressions do, meaning that the bottom condition (if true) will overrule other conditions. In the case here from what I can see, that leads my user to this Data Source being loaded into the RG


The :filter could be the culprit here. I don’t really see any reason for the UID not to be placed as a regular constraint on the search instead. Have you tried that on this specific condition?

1 Like

Thanks for looking into this. Yeah, after reading about how these operations work in the backend and front end with searches, I thought i’d change this. However putting the UID filter as a regular constraint hasn’t solved the issue.

I will keep playing with some other concepts you wrote about. If there’s anything I can do that might help you help me, let me know. Thanks.

Have you tried setting the Everyone else field in the User’s Privacy Rules to View all Fields and Find this in searches, basically making it completely open?

Not as a long-term solution, but to see if they are causing this after all. I’ve done a few more test runs, and no searches at all produce any results, no matter their conditions. I know you wrote that wasn’t it, but I have a hunch that it could still be it. I would try to perform a search afterwards with no conditions, just to check that you can get some results.

When I wrote it wasn’t, I clearly had no idea what I was writing because it is. haha. 5 days i’ve been banging my head against my keys and it was a permissions issue. Classic. Thanks for getting to the bottom of that one.

So this begs the question, why are the permissions not allowing access when the condition is ‘when user is logged in’ for access to this data?

Haha, glad we could take a step forward :slight_smile:

For your last question, it’s hard to say. There could be an issue with Bubble of course (some inconsistency on how Rules are applied in Logging in vs on Page Load). But there could also be some logical reason that we’re not seeing yet, that your further testing and development will reveal as you start reactivating the PR’s.

Do keep us posted if you learn something new!