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