[Resolved] three levels of relationships

[Author]

Posts

[chrisS-18]

I have three CPTs: Schools, Groups, and Members.

Each School can have multiple Groups (one to many)
Each Group can have multiple members (one to many)
Each member can be part of multiple Groups (one to many)
Each member can only be part of one school (one to one)

I think I understand the relationships between any two Post Types, but I'm trying to figure out how to get all three related together.

I need a form for each School to see their school's Group Members sorted by Group and be able add/subtract Group Members from each Group.

So School A would log in and see their school's information like this:

School A
-Group 1
---member1
---member2
---member3
-Group 2
---member1
---member4
---member5

Schools would be able to add or subtract Group Members from any Group. The new members would need to be created as new items in the Group Members post type when they are added to a Group.

Is it possible to do this?

OR would it be better to use taxonomies instead of CPTs for the Groups? So each School would see a list of Group Members by Group Taxonomy and assign new Group Members to that taxonomy? How would I set up a form like that?

thanks,
Chris

[Nigel]

Hi Chris

One observation about your relationships, there is no one-to-one relationship for Schools and Members, each Member is implicitly in a relationship with Schools and can belong to only one because of your other relationships, but you don't create a relationship between Schools and Members.

With the relationships you propose you would need nested Views to display the existing posts in the format

School A
-Group 1
---member1
---member2
---member3
-Group 2
---member1
---member4
---member5

So, you would insert a master View in the template for Schools which queried Groups and included a Query Filter to specify the School to which they belong (i.e. the post where the View is inserted).

So that first View loops over Groups of the current School.

It outputs its title (e.g. "Group 1"), and then a nested View.

This second View displays Members, and includes a Query Filter to specify the parent Group (i.e. the current post in the Loop).

So that will display everything in the format described above.

For deleting Members, do you mean that the Member post should be deleted, or simply removed from the Group?

Deleting in this scenario is trivial, you can include a cred_delete_post_link shortcode for each Member (https://toolset.com/documentation/user-guides/cred-shortcodes/#cred_delete_post_link).

Removing them from the Group isn't exactly difficult, but the workflow means that you have to edit the post (the Member) and unassign the Group parent, which takes you away from this page to the Member post where an edit form would be shown.

To add Members to a Group you effectively need either a link to an add new Member form, or the form itself, for each Group, so that you have the context to set the parent Group to which the Member will belong.

This is for adding new Members.

If you mean assigning existing Members to a Group, well for that you need to be editing Members and using the parent field to assign the Group, but I'm not sure how well that would work because you would have to list all Members then choose the one to edit.

Which leads me to the point that if you are talking about assigning/unassigning Members to Groups, rather then creating/deleting Members (within Groups), then you might need to approach this from the opposite direction, because you need to be editing Member posts to assign/unassign Groups, and so you might be better with a workflow that starts with Members and editing them and choosing the Group they belong to.

[chrisS-18]

Thank you for your thorough reply. I think it makes sense to start with the Members, like you suggested.

Two more questions:

1. I am importing existing Members and their associated Schools and Groups. They were pulled out of BuddyPress and need to be added to Toolset instead. This means I do actually have to create those Member-School relationships, after all, right? So when schools login, they will see their existing Members that I imported and can either edit those Members' Groups or add new Members and assign them to a Group.

2. Is this even the right approach? Or should I use taxonomies for Groups (instead of posts) and just assign Members to various Groups that way? Is that simpler?

My brain is all wrapped in knots sorting this out.....

thanks!

[Nigel]

Hi Chris

From your reply it sounds like option 2 might be the better way to go after all, because your Members already belong to a School, and it sounds like the issue is simply one of organising them in Groups.

If you have a 3-tier relationship you would need to duplicate the relationship information, because Members would implicitly belong to a School because of the Groups they are part of, but would need explicitly connecting to schools after all to know which school groups they could be added to.

So creating a one-to-many relationship for Schools >> Members seems the most appropriate way to tie Members to Schools, and then, yes, organise them into Groups with taxonomies (which is exactly what taxonomies are intended for).