I am still having trouble understanding how to add something to a list if things. The tricky part is that the list belongs to a different user.
Data type USER has a LIST OF CHILDREN. There is also a data type CHILDREN.
UserA logs in and adds children. This works OK. They can add as many children as they want and the children all get associated with UserA (the parent) using the LIST OF CHILDREN field on USER.
I am trying to find a way to have an option to work backwards. If I log in as a new user (UserB) without being associated to UserA (my parent), I want to be able to fill in the blank and add myself as a child of UserA.
I can easily add UserA as my parent on my data type USER (parent field). What I can’d figure out how to do is to add myself to the LIST OF CHILDREN on UserA.
I only see options for:
“Make changes to current user” - I want to add myself to the list of a DIFFERENT user.
“Create a new thing”
“Make changes to a thing”
“Make changes to a list of things”
Hey @katcabin-bubble I think the best way to structure this would be to make parents and children both Users. The benefit of this is also if you were to have a repeating group of a family, you can use a repeating group of users.
The way I would set it up is in this way:
The field ‘Parent’ is a yes/no field. If the user is a parent, the value is yes. If the user is a child, the value is no.
Then you can assign some sort of unique handle or username to each parent. In my example, I have a mother named Sally Jones, whose handle is SallyJones14. Her son is named Bobby Jones and his handle is BobbyJones14.
So if Bobby is logged in, and needs to be added as a child to his mother Sally’s list of children, he would input her unique username and then click ‘Add Me As Child’:
When ‘Add Me As Child’ is clicked, this is what it looks like in the workflow (we are making changes to a User (With the User being Sally, and the field we’re making a change to is her List of Children).
I agree both parents and children should be users and @fayewatson’s workflows get the job done.
Not sure what your app structure is like but if you had a repeating group of parents, then you could also “make a change to current cell’s user > list of children add current user” off the click of a button inside the cell.
I tend to find have markers on things that indicate their properties are awkward. Users are Users. Parents are Parents. Parents might also be Users that is true.
So whilst I would have the main repeating information on User, I might create two data types called Child and Parent and have User contained within it, as well as a list of Children (on the parent) and Parents (on the child).
I would do this because I feel it would make it easier to query later and I spend more time querying my data than creating it.
But that is just a guess, I would set up some of my functions with it to test it works in the various key journeys. Just quickly string some screens together to prototype.
You quickly get to understand if you data structure is right or wrong.
Wow thanks for all of the input! I think what confused me the most was making changes to the other user’s list. I still haven’t grasped the make changes to a user.
@fayewatson your screen shot of the “Make changes to User…” was initiated through what action?
I can’t get my field to just add current user like the @fayewatson example shows . It wants me to add something else after Current User and it gives me an issue that “make changes to User…: value should be a Referrals but right now it is a User”
Either your user_referrals field should be type user if it’s actually a list of users… (You can then add a user in the way you’re attempting in the screenshot)
OR you add a referral, not a user, to the list. You’ve defined user_referrals as a list of referrals, so you need to add a referral. You’re adding a user which is why it’s red. Your referral could then contain a user field and any other relevant information, and you’ll still be able to access the user attached to the referral.
No prob @katcabin-bubble! and I had a hard time grasping the differences in the data portion of the workflow at first too. Here’s how I think about “Make Changes to a Thing”.
I select “Make Changes to a Thing”
Bubble says: “Ok, what Thing are we changing here?”
Me: “Well since Bobby is logged in, we’re not changing the Current User (Bobby). We’re making changes to his mother, Sally.”
Bubble: “Right…Is Sally a User or a Referral… or…(insert any other Data Types here)? I need to know what data type she is, and then I can present the correct fields to you so you can actually make the changes you want.”
Me: “Sally is a User (or with Nigel’s data structure, she is a Parent). Let’s do a Search for Users, and to find her, find the user where his/her handle is = SallyJones14, which is the value Bobby entered in the Input.”
Bubble: “You’re forgetting that I don’t know ‘Handle’ is unique to each user! There could be 56 users with that Handle! Which User do you want me to change?”
Me: “There’s only one! I made the Handle unique!”
Bubble: “I have no idea what that means. When I search for Things, I will return all possible Users with that handle, even though you know it’s one, it COULD be 50! Or more! Maybe you were careless in structuring your app and two users found a way to both have the handle “SallyJones14”!. You need to make sure I am only making changes to ONE User or else I will turn red. If it’s unique just select ‘first item’ please.”
Me: “Ok will do!”
Then you’ve got the correct User (Sally), and you can make all of the changes you’d like to her fields (which either have one value such as ‘first name’, or are lists (multiple entries of a data type) such as ‘children’.
@fayewatson or anyone else that could help…
I’m trying to make this work…
When the current user adds a child (rep) that child also adds to the people above him. I’ve tried doing it like the picture below… those handle’s represent the groups about that user, however, the rep info doesn’t add to their lists…? Any help would be life saving at this point.
(by the way, it does add to the current user’s list just not the other users…)
You want “make a change to a list of things (users)” not a single user. From there, add the constraints you need to identify the users and then set up the my reps field to add the child.
So the My Reps (list) which is a user type, should have a field called Parent (or child) so that new rep thing adds to the my reps (list) on all the handles I’ve contrained?
Ok, I’ll follow up here from looking at your link…
All of your test users have empty handle values.
The constraint you have on that list of users is not saying “search for users who have one of these handles”. It’s saying “search for users who have all of these handles only” which is not what you’re going for, right? Every user will only have 1 handle. Maybe you can explain how the child’s parent is identified and we can figure out how to get the search constraints right. Is it users with these specific handles only? If so, try “Search for Users: handle = hhp :merged with Search for Users: handle = aci…” and so on. But I wonder if at some point these handles will by things you can’t anticipate, but you tell me how your structure works.
The action in general should do it. You’re making a change to a list of users and adding the new rep to their “my reps” field. We just need to identify the reps properly.
The handles are attached to the live users… Sorry… should have noted that.
Wow, that makes sense, I looked right past that logic. All of the handles represent a layer above the person adding the rep. I wanted to start with the deepest layer and work my way up with “only when this user is logged in” and constrain the users that sit above that way… So to add clarity, as the layers go up, the amount of handles will shrink by constraining through a workflow click (only when [x@x.com] is logged in. Let me try the merged with: option!
Sorry, it doesn’t have a colon in front. It’s just “merged with”… and remove handle. You’re just merging Users. So you’ll set the handle constraint on each of these searches, 1 handle per search. @1danielbaker
I think the best way to structure this would be to make parents and children both Users. The benefit of this is also if you were to have a repeating group of a family, you can use a repeating group of users.
