[Resolved] Is it possible to create a one-to-many USER relationship?

[Author]

Posts

[MichaelR9215]

Hello,

I am curious if I would be able to use the Toolset API to accomplish a development project I am working on.

Much like yout parent/child post relationship functionality, I am research how to create a parent/child user relationship.

Let me give you a little background:

I am building a website, similar to hidden link or hidden link ... it doesn't have to be as feature rich at first.

The website is an e-commerce website at its core (using WooCommerce), however, it is going to take on an MLM/Home Party structure.

The most simple form of this website could be ...

1.) Our e-commerce store with the main site owner (super admin).
2.) The site owner allows other people to become "consultants" of their product.
-- This Consultant earns commission from sales that they bring to the store.
-- I am using AffliateWP for this, as this sets up a user as an Affiliate of the website, and whenever a purchase is made, the Affiliate gets credit in the form of commission.
3.) The Consultant can also get someone else to do a "Home Party" for them.
-- A Home Party is fairly straight forward. First, the consultant "signs up" a Party Host. This is basically a person that is going to tell their friends to shop on the website.
-- The Party has a specific date range when customers can shop. On the specific dates of the "party", Customers will be able to go to a unique party page (that is connected to the Consultant). When a customer buys product from this party page:
a.) The site owner gets the money
b.) The consultant gets a commission
c.) The party host gets points to redeem free gifts/products
d.) The customer gets their product shipped to them

There is a lot going on here, but I have been thinking about the best way to build this out.

The first part is done using AffilateWP, and this functionality has given me a couple of ideas. When a user registers as a Consultant, they get their own unique referral URL that contains their Affiliate ID (hidden link"xyz"). When someone uses this URL, a number of tracking cookies are set, so the Affiliate/Consultant gets credit for anything that happens after that.

Ideally, A consultant can have a way to create a special invite URL that contains a sign up form for a party host (possibly CRED?). The consultant can go into some kind of front-end form that allows them to create as many new invite registration forms as they want (one for each party host). This creates an entry in a table that gives them a URL to send to a person they want to invite.

When the person signs up using this form, a special "party_host_id" can be added to the user database table, as well as an association to the referring Consultant (their Affiliate ID or User ID?) ... perhaps this can be done with CRED and User Fields, with a bit of API magic in there?

Once the parent/child connection is made (Consultant/Party Host ... Afilliate ID or User ID/Party_Host_ID or User ID), We would be able to do the same thing as the AffiliateWP plugin:

1.) A Consultant can then create a unique party page (perhaps again using CRED Post Forms with a Custom Post Type for the party posts?). This front-end party "post" creator would allow the Consultant to associate the party to one of their party hosts (now associated to them via the invite form registration)
2.) The Party post can be published, and we could create a unique party URL with some special variables. First, the original Affiliate ID can be associate to track the affiliate commission (by creating the affiliate cookies). Then, a new variable can be added for the party host ... something like hidden link"xyz"&party_host_id="xyz". When this is given to customers so they can shop, not only would the first part create the affiliate tracking cookies, but our second part can be programmed to create new party host tracking cookies.
3.) Customers shop, commission is given to the Affiliate, points are given to the party host (possible via myCRED points plugin) ...

Then, we can use all of the associations, with the Toolset API, WordPress, and other plugins to build ways for the Consultant to track certain data from each party, etc...

I don't know if any/all of this is possible using the existing Toolset Plugins, and API. I am willing to write some code, if I could possibly get some guidance as to where I should focus my attention.

Any suggestions based on your experience would be helpful and appreciated. I am trying to conceptualize everything, and fit the puzzle pieces together before I start coding.

I look forward to hearing from you!!

[Christian Cox]

Ideally, A consultant can have a way to create a special invite URL that contains a sign up form for a party host (possibly CRED?).
This isn't something that is automatically built-in to CRED, so you'll probably have to write some custom code that generates a GUID of some sort, then applies that GUID to a post custom field, along with the Consultant's ID. Set up a View that tests the custom field value against a URL parameter, and if a result is found then display your form or something.

When the person signs up using this form, a special "party_host_id" can be added to the user database table,
Sure, sounds like a User Custom field.

as well as an association to the referring Consultant (their Affiliate ID or User ID?) ... perhaps this can be done with CRED and User Fields, with a bit of API magic in there?
Yes, if we apply the Consultant's ID to a hidden field in the party host signup form, we can capture that value and store it in the party host's profile. In order to associate the Consultant ID with the party host signup form, we could store their ID along with the custom URL post field.

A Consultant can then create a unique party page (perhaps again using CRED Post Forms with a Custom Post Type for the party posts?). This front-end party "post" creator would allow the Consultant to associate the party to one of their party hosts (now associated to them via the invite form registration)
Okay sure, a new CRED form to create party posts, and associate a party host to that party post.

The Party post can be published, and we could create a unique party URL with some special variables.
Unique party URL is certainly possible with CRED. Then we could set up special links using wpv-post-url that append the necessary values to the URL automatically, and the consultant can copy + paste and distribute these modified links.

First, the original Affiliate ID can be associate to track the affiliate commission (by creating the affiliate cookies).
Then, a new variable can be added for the party host ... something like hidden link"xyz"&party_host_id="xyz".
So you'll use shortcodes to build out link URLs. This can be done in a loop to loop over party host IDs.

<a href="[wpv-post-url]?affiliate_id=[wpv-post-field name='wpcf-consultant-id']&party_host_id=[wpv-post-field name='wpcf-party-host-id']...

When this is given to customers so they can shop, not only would the first part create the affiliate tracking cookies, but our second part can be programmed to create new party host tracking cookies.
Cookie management is not really something Toolset is designed to do, so you'll be on your own for that part. I can help you get or set any Toolset field values necessary to facilitate this.

Customers shop, commission is given to the Affiliate, points are given to the party host (possible via myCRED points plugin)
Commission is given to the Affiliate how? It seems like once the cookie is set, then you'll need to interact with a WooCommerce API to capture the Affiliate ID from the cookie and perform some action when the order is completed. What that action is, I'm not sure - is it enough to update a custom field somewhere?

Points are given to the party host how? Again, it seems like you'll need to interact with a WooCommerce API to capture the party host ID from the cookie somehow, and perform some action when the order is completed, like an update_user_meta call that modifies some custom field value in the party host's profile - maybe a running total of points.

[MichaelR9215]

Christian,

I have been thoroughly enjoying discussing these possibilities with you! You are an awesome support technician. You have been paramount in the success of these development projects, and I am so appreciative.

To first answer your questions about the cookies, and assigning points and commission:
- I have already purchased the AffiliateWP plugin which already has built-in functionality that makes a person an affiliate. I am using Consultant and Affiliate interchangeably, as the end result is the same ... these users will earn a commission from various customer actions. AffiliateWP creates "referral URLs" with a query string that creates a tracking cookie. This tracking cookie (or more accurately multiple cookies) are used by the AffiliateWP plugin to award commissions, and I am sure a bunch more. These referral URLs can still be used by themselves, but I will also need custom urls that include the affiliate query strings from AffiliateWP, as well as my new strings to track party hosts, and the query strings to give me the ability to control a party page.
- So, if I had a URL 'website.com/referal_id="123"&party_host="123"&party_page="123"', that first "referral_id" would be the existing AffiliateWP id that is given to the affiliates, the second "party_host" would be for my own tracking cookie(s) ... I am planning on using myCRED for this. The third "party_page" would be to tack the page, where I can check the party dates attached to the party, change the content on the page, lock it, unlock it, etc...

Does this all make sense so far? I realize you wouldn't be able to help with the cookies. I already expected that. However, the ability to have all of the foundation code built out by Toolset would help enormously.

Ideally, A consultant can have a way to create a special invite URL that contains a sign up form for a party host (possibly CRED?).
- This isn't something that is automatically built-in to CRED, so you'll probably have to write some custom code that generates a GUID of some sort, then applies that GUID to a post custom field, along with the Consultant's ID. Set up a View that tests the custom field value against a URL parameter, and if a result is found then display your form or something.

I was thinking that this first part with the invite would be a CRED user form that creates a registration form that new party hosts would use to sign up.

So, thinking this through (and you can tell me if this sounds correct):
- I think that a consultant needs to invite the party hosts before a party page is created. This is because parties won't happen until a hosts set dates for their parties with their consultants.
- When a consultant sends an invite to a person, and that person fills out the new CRED user registration, they should be assigned a unique party_host_id in addition to the standard WordPress user ids and such. You mentioned a GUID from a custom post field, which confused me a bit. I was considering the party_host_id would be generated from a custom user field that adds the id into the user meta of the new user that registers.
- When you mentioned the custom post field, was your idea that the consultant would create a new post with a CRED post form that generated a unique invite post for each new party host, and the unique post contained a single CRED user form that pulled from the post's custom fields to create the unique party host connection to the consultant?

When the person signs up using this form, a special "party_host_id" can be added to the user database table,
Sure, sounds like a User Custom field.

- As mentioned above, this makes sense ... I guess where I am having trouble connecting the dots is how the invite url is created for each party host.
- I suppose the consultant having the ability to create custom posts can work ... it seems like overkill to create a post for every invite. Perhaps this can be a custom url builder that simply generates a new url with some query strings attached that we can tap into from the CRED user form. Would this be harder than just using a new post every time, and adding a view to the custom post type that hold a single CRED user form?

Yes, if we apply the Consultant's ID to a hidden field in the party host signup form, we can capture that value and store it in the party host's profile. In order to associate the Consultant ID with the party host signup form, we could store their ID along with the custom URL post field.

- Would this be similar to how we created the checklist, where the user field would be a repeating single field? Then we'd add it to the CRED user form, and hide it with CSS?

Okay sure, a new CRED form to create party posts, and associate a party host to that party post. Unique party URL is certainly possible with CRED. Then we could set up special links using wpv-post-url that append the necessary values to the URL automatically, and the consultant can copy + paste and distribute these modified links.
- I'm still thinking through the process a bit, but I think that:
-- A.) Consultants invite Hosts
-- B.) Either consultants create a new party page and associate a host to it, OR a host requests a new party page, and then the consultant creates a party page, and the user who requested it is added. Hosts should have minimal access rights, so they shouldn't be able to create their own parties.
-- C.) Maybe the consultant and host can have a page that shows them what parties they're associated to, and the urls of those parties, so they can easily see all the parties in date order, and copy the urls to send to customers.
- So, going back to what you said, a consultant has a CRED post form, they create new party pages, those party pages would have a unique party_page_id, then I am still thinking about how to get the party host associated to the party page.
-- Can a party host be associated to the page after it is created, or in order to use CRED, it would have to be done when the new page is created with the form?
- The special links can be created by using a view to loop through all of the parties, and building them with all of the variables that we created during the processes above...correct?

<a href="[wpv-post-url]?affiliate_id=[wpv-post-field name='wpcf-consultant-id']&party_host_id=[wpv-post-field name='wpcf-party-host-id']...

------------

I think I covered everything. Does it all make sense? I believe we can do a good portion of it with Toolset, of course with some custom code to pull it all together on my end.

What do you think? If I can get a little more clarification about the above, I should be in good shape to begin making this happen.

[Christian Cox]

- When a consultant sends an invite to a person, and that person fills out the new CRED user registration, they should be assigned a unique party_host_id in addition to the standard WordPress user ids and such. You mentioned a GUID from a custom post field, which confused me a bit. I was considering the party_host_id would be generated from a custom user field that adds the id into the user meta of the new user that registers.
A PHP GUID is a way of generating that unique id string, but if you have another method of generating a unique ID that's fine too. You will add that into the user meta of the new user.

- When you mentioned the custom post field, was your idea that the consultant would create a new post with a CRED post form that generated a unique invite post for each new party host, and the unique post contained a single CRED user form that pulled from the post's custom fields to create the unique party host connection to the consultant?
Yes, that was what I was thinking. This way each invite post generated by the Consultant lives at its own unique URL and would include all the information you would need to associate a Party Host and a Consultant with each other during the submission of a new user post form, using cred_save_data.

- As mentioned above, this makes sense ... I guess where I am having trouble connecting the dots is how the invite url is created for each party host.
Okay this is where I thought a GUID might be helpful, because you can use one to construct a unique URL for each invite. This can be used in one of two ways. It can be used as the title and slug of a unique Invite post, so each invite lives at yoursite.com/invite/somelongstringguid. Or, it can be applied as a URL parameter to a single URL, like yoursite.com/invite?inviteid=somelongsstringguid. You will capture either the slug or the URL parameter in the signup form using a hidden field.

I suppose the consultant having the ability to create custom posts can work ... it seems like overkill to create a post for every invite
Sure, I see what you mean. Now that I'm thinking through this in more detail, what's the point of making a unique URL for each party host? It seems like a Consultant would give out the same URL to all his potential party hosts. That URL could be based on the Consultant ID, and the CRED form that exists on that URL could capture the Consultant ID to store with the new Party Host's profile. The GUID would come into play at that point, because you need to generate a unique Party Host ID to store in the Party Host's User profile as well. You'll do that using a cred_save_data or cred_before_save_data hook. But I don't really see the need for unique URLs for each Party Host, only unique URLs for each Consultant. Correct me if I'm wrong there.

Would this be similar to how we created the checklist, where the user field would be a repeating single field? Then we'd add it to the CRED user form, and hide it with CSS?
We're talking about the Consultant ID field on the Party Host profile, correct? It's a one-to-many relationship so I thought a single field would be sufficient - just the ID of the Consultant who gave them a signup link.

-- Can a party host be associated to the page after it is created, or in order to use CRED, it would have to be done when the new page is created with the form?
Your Consultants can use Edit CRED Forms to edit a Party page. In that edit form, you can include a select field where they can choose from their active Party Hosts. Then when they submit the form, the Party is updated to include the Party Host's ID. To show a Party Host a list of their Parties, you will create a View that shows Parties filtered by a custom field, where that custom field value is equal to the current User's ID.

- The special links can be created by using a view to loop through all of the parties, and building them with all of the variables that we created during the processes above...correct?
Yes, it will be simple if all the variables you need to associate with those URLs are stored as custom fields on the Party post type. This way your Loop can access all that information within the context of the current post in the Loop (meaning you don't have to query other post types for related information). So when the Consultant creates a Party post, his/her ID should be stored in a custom field for that Party. When the Consultant wants to assign that Party to a Party Host, then he/she will edit that Party post using a CRED edit form and attach the Host's ID to the party. So that will give you access to Party post URL, Host ID and Consultant ID within the context of the Party post.

I think I covered everything. Does it all make sense?
I think I get the main point here, it's going to take a bit of trial and error to make sure you get the custom URLs and custom field structures right, figure out what gets saved where, and how relationships between things are maintained. But none of it sounds impossible with Toolset and a bit of assistance using the CRED API.

[MichaelR9215]

Christian,

This correspondence had given me the foundation to begin working out the code. I thank you so much for that.

May I keep this thread open, so we can correspond further as I begin this process?

I believe I have a good handle on the key concepts, and how to utilize Toolset for each component.

One other question I have is regarding the reuse of this concept for other sites (should I run into a situation where I need this again). Is there a way to build all of this, and similar to what you have for the Genesis Framework, give me the ability to save all of the components out to import into a new site? I believe your Genesis Framework import is for Layouts, where you have prebuilt layouts that are created with the push of a button. Can the same thing be set up for CRED forms, Views, CPTs, and my custom code (that I will most likely be writing into one self-contained plugin or mu-plugin).

Thanks again! I'll keep you posted with my progress.

[Christian Cox]

Glad to help!

May I keep this thread open, so we can correspond further as I begin this process?
Sure, I will mark this ticket as pending an update from you. No need to reply right away. The ticket will remain open for 30 days unless you reply before then.

One other question I have is regarding the reuse of this concept for other sites (should I run into a situation where I need this again). Is there a way to build all of this, and similar to what you have for the Genesis Framework, give me the ability to save all of the components out to import into a new site?
To some degree, yes - it's called Toolset Module Manager and it's available in your account downloads area. It will help you create modules that represent your data structures, post types, taxonomies, relationships, custom fields, layouts, archives, etc., then export those structures to other sites. It's not designed to help you export content, like individual posts or terms or custom field values, but it can get your admin configured quickly to begin accepting that new content.
https://toolset.com/home/module-manager/
https://toolset.com/documentation/user-guides/using-toolset-module-manager/