Hey you're welcome. You're on the right track to be thinking about the privacy rules here. The tutorial was always involved and longer than average so it skipped the topic. An obvious thing to note in this feature build is that the person doing the inviting is the owner of the account/team and has special admin powers which allows them to build a team (list of users) of some kind. Or I suppose even in the case of a user stacking up referral bonus invites, they're still the 'king/queen' of their castle and inviting others into it. Hence, in either scenario you would give the owner/admin user a field somewhere that is a list of users they've invited. It could exist wherever you see fit in your data structure and it potentially could also be shared list that is on a Team data type, if your app is of this style, as many modern apps often have multiple admin user types. Finally then, in the privacy rules you would make any given Pending Invite item in the database visible only it is contained in the Current User list of Pending Invites. Hope that helps.
great video! I wonder if it will work on a large database of users? As the invite function workflow searches through the entire user database (condition for new or existing users). How fast can bubble scan through, say 10K users database? Should we add a workflow pause on the invites?
Hey thanks, good question. One solution might be to trigger a backend API workflow when the invite button is clicked and offload any big lookups there so it doesn't slow down front end user experience. Because then it wouldn't matter how fast bubble scans that many records, it'd just be off doing its thing. And if you wanted to give the user immediate visual feedback that this person has been "invited", you could buffer the front end display for a few seconds with a state variable until the full backend workflows have run. My general stance though on optimization is that there is a balance to considering the long-term impact of decisions upfront -- which you'd do we to consider because it does make an impact. But also consider how paralysis of analysis will play into things versus built it and keep a "future optimizations" list so when your app gains 10k users, well hot d*mn there'd be a lot of paying users and therefore a lot money to pay someone to solve any optimization challenges down the road 😄.
hi! really good content!! i wonder how to redirect the person that already has an app to the shared space? because after following your tutorial it just says: " you are already registered" and the user just gets stuck there thank you in advance!
Hi great question -- the missing piece is a few workflows to check what is the situation with the current user. First, for users who have accounts AND are logged in -- add an "on page load" event that checks if the user is already signed in, then (a) run the workflows that add the person to the shared space and (b) redirect them there. Second, for users for have accounts BUT are not logged in -- they'd login as per usual but have some conditional checks on the login button that if they're not already added to the workspace that they're accepting the invite to join, then (a) run the workflows that add the person to the shared space and (b) redirect them there. Hope that helps.
Hey Armand, thanks for the comment. G - Table Header is a group with a text element for each column to serve as a label. It's inside of the repeating group, but as seen in 5:36 mark, the conditional if the current cell is not the first row, then it won't show. Said another way, G - Table Header is programmed to only show on the first row at the top of the repeating group. Hope that helps.
This was really useful. One of the few instruction videos I didn't set to 2x speed 😂
Haha thank you brother, glad it was helpful.
Super useful!
Glad to hear it!
Thank you for this very useful video.
You're welcome
me salvou.... thanks!!
Thanks for the video; it was very useful. I wonder how you would set privacy rules. Can all the users see all the PendingInvites records?
Hey you're welcome.
You're on the right track to be thinking about the privacy rules here. The tutorial was always involved and longer than average so it skipped the topic.
An obvious thing to note in this feature build is that the person doing the inviting is the owner of the account/team and has special admin powers which allows them to build a team (list of users) of some kind. Or I suppose even in the case of a user stacking up referral bonus invites, they're still the 'king/queen' of their castle and inviting others into it.
Hence, in either scenario you would give the owner/admin user a field somewhere that is a list of users they've invited. It could exist wherever you see fit in your data structure and it potentially could also be shared list that is on a Team data type, if your app is of this style, as many modern apps often have multiple admin user types.
Finally then, in the privacy rules you would make any given Pending Invite item in the database visible only it is contained in the Current User list of Pending Invites. Hope that helps.
great video!
I wonder if it will work on a large database of users?
As the invite function workflow searches through the entire user database (condition for new or existing users). How fast can bubble scan through, say 10K users database? Should we add a workflow pause on the invites?
Hey thanks, good question. One solution might be to trigger a backend API workflow when the invite button is clicked and offload any big lookups there so it doesn't slow down front end user experience. Because then it wouldn't matter how fast bubble scans that many records, it'd just be off doing its thing. And if you wanted to give the user immediate visual feedback that this person has been "invited", you could buffer the front end display for a few seconds with a state variable until the full backend workflows have run.
My general stance though on optimization is that there is a balance to considering the long-term impact of decisions upfront -- which you'd do we to consider because it does make an impact. But also consider how paralysis of analysis will play into things versus built it and keep a "future optimizations" list so when your app gains 10k users, well hot d*mn there'd be a lot of paying users and therefore a lot money to pay someone to solve any optimization challenges down the road 😄.
hi! really good content!!
i wonder how to redirect the person that already has an app to the shared space?
because after following your tutorial it just says: " you are already registered" and the user just gets stuck there
thank you in advance!
and it seems that user has always to sign up when he does not really need to
Hi great question -- the missing piece is a few workflows to check what is the situation with the current user.
First, for users who have accounts AND are logged in -- add an "on page load" event that checks if the user is already signed in, then (a) run the workflows that add the person to the shared space and (b) redirect them there.
Second, for users for have accounts BUT are not logged in -- they'd login as per usual but have some conditional checks on the login button that if they're not already added to the workspace that they're accepting the invite to join, then (a) run the workflows that add the person to the shared space and (b) redirect them there. Hope that helps.
Hello :) Can someone describe how the G - Table Header is configured please ?
Hey Armand, thanks for the comment. G - Table Header is a group with a text element for each column to serve as a label. It's inside of the repeating group, but as seen in 5:36 mark, the conditional if the current cell is not the first row, then it won't show. Said another way, G - Table Header is programmed to only show on the first row at the top of the repeating group. Hope that helps.
Really helpful tutorial, but I had to watch in 0.75x speed 😅
This one is a head spinner -- worth to watch twice and take notes. There's a lot going on ✌🤠.